Red Hat Training
A Red Hat training course is available for RHEL 8
Configuração e gerenciamento da Gestão de Identidade
Configuração, gerenciamento e manutenção do Gerenciamento de Identidade no Red Hat Enterprise Linux 8
Resumo
Tornando o código aberto mais inclusivo
A Red Hat tem o compromisso de substituir a linguagem problemática em nosso código, documentação e propriedades da web. Estamos começando com estes quatro termos: master, slave, blacklist e whitelist. Por causa da enormidade deste esforço, estas mudanças serão implementadas gradualmente ao longo de vários lançamentos futuros. Para mais detalhes, veja a mensagem de nosso CTO Chris Wright.
Fornecendo feedback sobre a documentação da Red Hat
Agradecemos sua contribuição em nossa documentação. Por favor, diga-nos como podemos melhorá-la. Para fazer isso:
Para comentários simples sobre passagens específicas:
- Certifique-se de que você está visualizando a documentação no formato Multi-page HTML. Além disso, certifique-se de ver o botão Feedback no canto superior direito do documento.
- Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
- Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
- Siga as instruções apresentadas.
Para enviar comentários mais complexos, crie um bilhete Bugzilla:
- Ir para o site da Bugzilla.
- Como Componente, use Documentation.
- Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s) parte(s) relevante(s) da documentação.
- Clique em Submit Bug.
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.
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.
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
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árioadmin
:[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
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, apenasexample_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
Para destruir seu bilhete Kerberos:
[exemplo_utilizador@servidor ~]$ kdestroy
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
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çãoNão sobrescreva o arquivo
krb5.conf
existente no sistema externo.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.-
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)
, ekdestroy(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
ekadmin
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
ewinbind
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.
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.
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.
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 Identity
→ Services
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
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.
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
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 Identity
→ Services
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.- Versão de exibição com comandos
ipa
A partir da linha de comando, use o comando
ipa --version
.[root@server ~]# ipa --version VERSION: 4.8.0, API_VERSION: 2.233
- Versão de exibição com comandos
rpm
Se os serviços da IdM não estiverem funcionando corretamente, você pode usar o utilitário
rpm
para determinar o número da versão do pacoteipa-server
que está atualmente instalado.[root@server ~]# rpm -q ipa-server ipa-server-4.8.0-11.module+el8.1.0+4247+9f3fd721.x86_64
Capítulo 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
Servidor IdM instalado e acessível.
Para detalhes, consulte Instalando o Gerenciamento de Identidade.
Para usar a interface de linha de comando IPA, autentique ao IdM com um bilhete Kerberos válido.
Para obter detalhes sobre como obter um bilhete Kerberos válido, consulte Login para Gerenciamento de Identidade a partir da linha de comando.
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 apenasipa 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ásicoipa help
. -
topics
- You pode executar o comandoipa 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 comandoipa 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
- Abra o terminal e conecte-se ao servidor IdM.
Digite
ipa help topics
para exibir uma lista de tópicos cobertos pela ajuda.$ ipa help topics
Selecione um dos tópicos e crie um comando de acordo com o seguinte padrão:
ipa help [topic_name]
, em vez da stringtopic_name
, adicione um dos tópicos listados na etapa anterior.No exemplo, utilizamos o seguinte tópico
user
$ ipa help user
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
- Abra o terminal e conecte-se ao servidor IdM.
Digite
ipa help commands
para exibir uma lista de comandos cobertos pela ajuda.$ ipa help commands
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
- Abra o terminal e conecte-se ao servidor IdM.
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.
- No campo First name:, digite o primeiro nome do novo usuário e pressione a tecla Enter.
- No campo Last name:, digite o sobrenome do novo usuário e pressione a tecla Enter.
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
- Abra o terminal e conecte-se ao servidor IdM.
Digite o comando para adicionar uma senha:
$ ipa user-mod euser --password
O comando executa um script onde você pode adicionar a nova senha.
- 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.
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
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
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
-
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:
- Faça o login na IDM Web UI.
Clique em IPA Server.
- Na aba IPA Server, clique em Configuration.
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
Clique em Save na parte superior da página.
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:
Bilhete Kerberos
Para maiores detalhes, ver Seção 6.1, “Autenticação Kerberos na Gestão da Identidade”.
Cartão inteligente
Para detalhes, veja Configurando o servidor IdM para autenticação de Cartão Smart Card.
A senha única (OTP) - this pode ser combinada com a senha e autenticação Kerberos.
Para maiores detalhes, ver Seção 7.2, “Autenticação de senha única (OTP) na Gestão de Identidade”.
Procedimento
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.
- 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.
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.
- Clique em Log in.
Após o login bem sucedido, você pode começar a configurar o servidor IdM.
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
Servidor IdM instalado em seu ambiente de rede
Para detalhes, veja Instalando o Gerenciamento de Identidade no Red Hat Enterprise Linux 8
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:
o cliente da IdM
Para detalhes, consulte Preparando o sistema para a instalação do cliente de Gerenciamento de Identidade.
- o pacote krb5conf
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.
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
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árioadmin
:[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
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, apenasexample_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
- Abra o diálogo de login da IDM Web UI em seu navegador da web.
Clique no link para configuração do navegador na tela de login da Web UI.
Siga os passos na página de configuração.
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”.
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
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çãoNão sobrescreva o arquivo
krb5.conf
existente no sistema externo.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.-
Copie os trechos de configuração Kerberos do diretório
/etc/krb5.conf.d/
para o sistema externo. - 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.
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
- Entre na IDM Web UI com seu nome de usuário e senha.
Abra a aba Identity → Users → Active users.
- Clique em seu nome de usuário para abrir as configurações do usuário.
- No site User authentication types, selecione Two factor authentication (password OTP).
- 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
- Entre na IDM Web UI com seu nome de usuário e senha.
- Para criar a ficha em seu telefone celular, abra a aba Authentication → OTP Tokens.
Clique em Add.
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.
- Copie o código QR em seu telefone celular.
- Clique em OK para fechar o código QR.
Agora você pode gerar senhas únicas e fazer login com elas na IDM Web UI.
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
- 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.
- Adicione a senha para o nome de usuário digitado acima.
- Gerar uma senha única em seu dispositivo.
- Digite a senha única logo após a senha (sem espaço).
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.
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
Na tela de login da IDM Web UI, clique em Sync OTP Token.
- Na tela de login, digite seu nome de usuário e a senha de Gerenciamento de Identidade.
- Gerar uma senha única e inseri-la no campo First OTP.
- Gerar outra senha de uma vez e inseri-la no campo Second OTP.
Opcionalmente, digite a identificação simbólica.
- 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
- Na tela de login de expiração da senha, digite o nome do usuário.
- Adicione a senha para o nome de usuário digitado acima.
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.
- Digite a nova senha duas vezes para verificação.
Clique em Reset Password.
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
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
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 }}"
Adapte o arquivo alterando o seguinte:
- A senha do administrador da IdM.
- Outros valores, se necessário.
- Salvar o arquivo.
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
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
.
-
A senha do administrador da IdM definida pela variável
- Salvar o arquivo.
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:
Acesse
ipaserver
como administrador da IdM:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
-
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. Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
.
-
A senha do administrador da IdM definida pela variável
- Salvar o arquivo.
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:
Acesse
ipaserver
como administrador da IdM:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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.
Você pode excluir permanentemente as entradas do usuário do banco de dados do IdM.
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.
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
.
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
- Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
- Obtenção de um bilhete Kerberos. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
- Abra o terminal e conecte-se ao servidor IdM.
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_.$-]?
NotaOs 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
- Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
- Obtenção de um bilhete Kerberos. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
- Abra o terminal e conecte-se ao servidor IdM.
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
- Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
- Obtenção de um bilhete Kerberos. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
- Abra o terminal e conecte-se ao servidor IdM.
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
- Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
- Obtenção de um bilhete Kerberos. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
- Abra o terminal e conecte-se ao servidor IdM.
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
- Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
- Obtenção de um bilhete Kerberos. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
- Abra o terminal e conecte-se ao servidor IdM.
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.
Você pode excluir permanentemente as entradas do usuário do banco de dados do IdM.
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.
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.
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
Faça o login na IDM Web UI.
Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
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.
- Clique no ícone Add.
- Na caixa de diálogo Add stage user, digite First name e Last name do novo usuário.
[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.
- [Opcional] No menu suspenso GID, selecione os grupos nos quais o usuário deve ser incluído.
- [Opcional] Nos campos Password e Verify password,
Clique no botão Add.
Neste ponto, você pode ver a conta de usuário na tabela Stage Users.
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
Faça o login na IDM Web UI.
Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
- Vá para a guia Users → Stage users.
- Clique na caixa de seleção da conta de usuário que você deseja ativar.
Clique no botão Activate.
- 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.
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.
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
Faça o login na IDM Web UI.
Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
- Vá para a guia Users → Active users.
- Clique na caixa de seleção das contas de usuário que você deseja desativar.
Clique no botão Disable.
- 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.
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
- Faça o login na IDM Web UI.
- Vá para a guia Users → Active users.
- Clique na caixa de seleção das contas de usuário que você deseja habilitar.
Clique no botão Enable.
- 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.
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
Faça o login na IDM Web UI.
Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
- Vá para a guia Users → Active users.
- Clique na caixa de seleção das contas de usuário que você deseja preservar.
Clique no botão Delete.
- Na caixa de diálogo Remove users, mude o botão de rádio Delete mode para preserve.
Clique no botão Delete.
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
Faça o login na IDM Web UI.
Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
- Vá para a guia Users → Preserved users.
- Clique na caixa de seleção nas contas de usuário que você deseja restaurar.
Clique no botão Restore.
- 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:
Preservação temporária dos usuários
Para obter detalhes, consulte a seção Preservando usuários ativos na interface web da IdM.
- Eliminando-as permanentemente
- 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
Faça o login na IDM Web UI.
Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
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.
- Clique no ícone Delete.
- Na caixa de diálogo Remove users, mude o botão de rádio Delete mode para delete.
- 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:
-
Garantindo a presença de um único usuário listado diretamente no arquivo
YML
. -
Assegurando a presença de múltiplos usuários listados diretamente no arquivo
YML
. -
Garantir a presença de múltiplos usuários listados em um arquivo
JSON
que é referenciado a partir do arquivoYML
. -
Assegurando a ausência de usuários listados diretamente no arquivo
YML
.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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.NotaSe 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.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
:Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicite um bilhete Kerberos para administração:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
NotaSe 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.
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
:Acesse
ipaserver
como administrador:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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 }}"
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" } ] }
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
:Acesse
ipaserver
como administrador:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
:
Acesse
ipaserver
como administrador:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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áveisipauser
. -
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), egidNumber
, 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 grupo | Membros do grupo padrão |
---|---|
| Todos os usuários da IdM |
|
Usuários com privilégios administrativos, incluindo o usuário padrão |
| Este é um grupo legado que não tem mais nenhum privilégio especial |
| 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
.
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
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
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 aipa group-add
:-
--nonposix
para criar um grupo não-POSIX --external
para criar um grupo externoPara detalhes sobre os tipos de grupo, veja Os diferentes tipos de grupo na IdM.
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 aipa 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.
-
Exibir todos os grupos POSIX usando o comando
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
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 deDOMAIN\user_name
ouuser_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.
-
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.
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:
- Adicionar um novo usuário sem um UPG, sem desabilitar grupos privados globalmente. Veja Adicionar um usuário sem um grupo privado de usuários quando os grupos privados são habilitados globalmente.
- Desativar UPGs globalmente para todos os usuários, depois adicionar um novo usuário. Veja Desabilitando grupos privados de usuários globalmente para todos os usuários e Adicionando um usuário quando grupos privados de usuários são globalmente desabilitados.
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.
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 comandoipa 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
Obter privilégios de administrador:
$ parentes admin
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
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
NotaPara reativar a instância
UPG Definition
mais tarde, use o comandoipa-managed-entries -e "UPG Definition" enable
.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
- As UPGs devem ser desativadas globalmente para todos os usuários. Para mais informações, consulte Desabilitando grupos privados de usuários em todo o mundo para todos os usuários
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 comandoipa 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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
- 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
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 dogroup_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 dogroup_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 dogroup_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 dogroup_a
.
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
NotaA 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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
-
Optional. Use o comando
ipa group-show
para confirmar que o grupo inclui o membro que você deseja remover. 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 deDOMAIN\user_name
ouuser_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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
- 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
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 dogroup_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 dogroup_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 dogroup_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 dogroup_a
.
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), egidNumber
, 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 grupo | Membros do grupo padrão |
---|---|
| Todos os usuários da IdM |
|
Usuários com privilégios administrativos, incluindo o usuário padrão |
| Este é um grupo legado que não tem mais nenhum privilégio especial |
| 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
.
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
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
- Clique em Identity → Groups, e selecione User Groups na barra lateral esquerda.
- Clique em Add para começar a adicionar o grupo.
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.
- 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
- Clique em Identity → Groups e selecione User Groups.
- Selecione o grupo a ser excluído.
- Clique em Delete.
- 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
- Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
- Clique no nome do grupo.
Selecione o tipo de membro do grupo que você deseja adicionar: Users, User Groups, ou External.
- Clique em Add.
- Selecione a caixa de seleção ao lado de um ou mais membros que você deseja adicionar.
Clique na seta para a direita para mover os membros selecionados para o grupo.
- 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
- Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
- Clique no nome do grupo.
Selecione o tipo de gerente do grupo que você deseja adicionar: Users ou User Groups.
- Clique em Add.
- Selecione a caixa de seleção ao lado de um ou mais membros que você deseja adicionar.
Clique na seta para a direita para mover os membros selecionados para o grupo.
- Clique em Add para confirmar.
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:
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
- Selecione Identity → Groups.
- Selecione User Groups na barra lateral esquerda.
- Clique no nome do grupo que você deseja visualizar.
Alternar entre Direct Membership e Indirect Membership.
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
- Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
- Clique no nome do grupo.
Selecione o tipo de membro do grupo que você deseja remover: Users, User Groups, ou External.
- Selecione a caixa de seleção ao lado do membro que você deseja remover.
- Clique em Delete.
- 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
- Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
- Clique no nome do grupo.
Selecione o tipo de gerente membro que você deseja remover: Users ou User Groups.
- Selecione a caixa de seleção ao lado do gerente membro que você deseja remover.
- Clique em Delete.
- Clique em Delete para confirmar.
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:
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
- Você sabe a senha do administrador da IdM.
- Você instalou o pacote ansible-freeipa no controlador Ansible.
- Os usuários que você deseja consultar em seu Livro de Jogadas Ansíveis existem na IdM. Para detalhes sobre como garantir a presença de usuários que utilizam Ansible, consulte Gerenciando contas de usuários utilizando Ansible playbooks.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
:
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
:
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
:
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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:
- Benefícios da associação automática em grupo
- Regras de membros automáticos
- Adicionando uma regra de membro automático usando IdM CLI
- Adicionando uma condição a uma regra de membro automático usando IdM CLI
- Visualização das regras existentes de membros automáticos usando IdM CLI
- Eliminação de uma regra de membro automático usando IdM CLI
- Removendo uma condição de uma regra de membro automático usando IdM CLI
- Aplicação de regras de membros automáticos às entradas existentes usando IdM CLI
- Configuração de um grupo de membros automáticos padrão usando IdM CLI
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).
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.
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
- O grupo-alvo da nova regra deve existir na IdM.
Procedimento
-
Digite o comando
ipa automember-add
para adicionar uma regra de membro automático. 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
- Você pode exibir as regras e condições de membros automáticos existentes no IdM usando a visualização das regras de membros automáticos existentes usando o IdM CLI.
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
- A regra do alvo deve existir na IdM. Para detalhes, veja Adicionar uma regra de membro automático usando o IdM CLI.
Procedimento
-
Definir uma ou mais condições inclusivas ou exclusivas usando o comando
ipa automember-add-condition
. 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
- Você pode exibir as regras e condições de membros automáticos existentes no IdM usando a visualização das regras de membros automáticos existentes usando o IdM CLI.
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
-
Digite o comando
ipa automember-find
. 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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
-
Digite o comando
ipa automember-del
. 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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
Procedimento
-
Digite o comando
ipa automember-remove-condition
. 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.
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
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
- Você deve estar logado como administrador. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
- O grupo alvo que você deseja definir como padrão existe na IdM.
Procedimento
-
Digite o comando
ipa automember-default-group-set
para configurar um grupo de membros automáticos padrão. 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
NotaPara 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:
- Benefícios da associação automática em grupo
- Regras de membros automáticos
- Adicionando uma regra de membro automático usando IdM Web UI
- Adicionando uma condição a uma regra de membro automático usando IdM Web UI
- Visualizando as regras e condições de membros automáticos existentes usando IdM Web UI
- Eliminação de uma regra de membro automático usando IdM Web UI
- Removendo uma condição de uma regra de membro automático usando IdM Web UI
- Aplicação de regras de membros automáticos às entradas existentes usando a interface Web do IdM
- Configuração de um grupo de usuários padrão usando o IdM Web UI
- Configuração de um grupo hospedeiro padrão usando o IdM Web UI
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).
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.
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
- Clique Identity → Automember, e selecione User group rules ou Host group rules.
- Clique em Add.
No campo Automember rule, selecione o grupo ao qual a regra será aplicada. Este é o nome do grupo-alvo.
- Clique em Add para confirmar.
- 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
- Clique Identity → Automember, e selecione User group rules ou Host group rules.
- Clique na regra à qual você deseja acrescentar uma condição.
Nas seções Inclusive ou Exclusive, clique em Adicionar.
- No campo Attribute, selecione o atributo desejado, por exemplo uid.
- No campo Expression, defina uma expressão regular.
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).
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
- Clique em Identity → Automember, e selecione User group rules ou Host group rules para visualizar as respectivas regras de membros automáticos.
Opcional: Clique em uma regra para ver as condições para essa regra nas seções Inclusive ou Exclusive.
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
- Clique em Identity → Automember, e selecione User group rules ou Host group rules para visualizar as respectivas regras de membros automáticos.
- Selecione a caixa de seleção ao lado da regra que você deseja remover.
Clique em Delete.
- 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
- Clique em Identity → Automember, e selecione User group rules ou Host group rules para visualizar as respectivas regras de membros automáticos.
- Clique em uma regra para ver as condições para essa regra nas seções Inclusive ou Exclusive.
- Selecione a caixa de seleção ao lado das condições que você deseja remover.
Clique em Delete.
- 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.
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
- Selecione Identity → Users ou Hosts.
Clique Actions → Rebuild auto membership.
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
- Selecione Identity → Users ou Hosts.
- Clique no nome do usuário ou host desejado.
Clique Actions → Rebuild auto membership.
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
- Clique em Identity → Automember, e selecione User group rules.
No campo Default user group, selecione o grupo que você deseja definir como o grupo de usuário padrão.
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
- Clique em Identity → Automember, e selecione Host group rules.
No campo Default host group, selecione o grupo que você deseja definir como o grupo anfitrião padrão.
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.
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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
Procedimento
-
Optional: Exibir as regras de auto-atendimento existentes com o comando
ipa selfservice-find
. -
Optional: Mostrar detalhes da regra de autoatendimento que você deseja modificar com o comando
ipa selfservice-show
. -
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
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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
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.
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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
Procedimento
- Abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Self Service Permissions.
Clique em Add na parte superior direita da lista das regras de acesso de auto-atendimento:
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:
- Selecione as caixas de seleção ao lado dos atributos que você deseja que os usuários sejam capazes de editar.
Optional: Se um atributo ao qual você gostaria de fornecer acesso não estiver listado, você pode adicionar uma listagem para ele:
- Clique no botão Add.
- Digite o nome do atributo no campo de texto Attribute da seguinte janela Add Custom Attribute.
- Clique no botão OK para adicionar o atributo
- Verificar se o novo atributo está selecionado
-
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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
Procedimento
- Abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Self Service Permissions.
Clique no nome da regra de auto-atendimento que você deseja modificar.
- 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.
- 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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
Procedimento
- Abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Self Service Permissions.
Selecione a caixa de seleção ao lado da regra que você deseja excluir, depois clique no botão Delete, à direita da lista.
- 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.
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 atributodisplayname
à regra de exemplobasic 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
- A partir do menu IPA Server, clique Role-Based Access Control → Delegations.
Clique em Add.
Na janela Add delegation, faça o seguinte:
- Nomear a nova regra da delegação.
- 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).
- 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.
- 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
A partir do menu IPA Server, clique Role-Based Access Control → Delegations.
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
A partir do menu IPA Server, clique Role-Based Access Control → Delegations.
- Clique sobre a regra que você deseja modificar.
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.
- 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
- A partir do menu IPA Server, clique Role-Based Access Control → Delegations.
- Selecione a caixa de seleção ao lado da regra que você deseja remover.
Clique em Delete.
- 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.); conjuntossubtree
etarget filter
-
memberof
: membros de um grupo; estabelece umtarget filter
-
targetgroup
: concede acesso para modificar um grupo específico (como a concessão dos direitos de administrar a adesão ao grupo); estabelece umtarget
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.
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.
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
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.
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.
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.
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
Papel | Privilégio | Descriçã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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
Procedimento
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
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 argumentosall
,anonymous
, epermission
. O tipo de vinculaçãopermission
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ãopermission
é o valor padrão.NotaNã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ãoadd
,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}
Notaadd
edelete
são operações de nível básico (por exemplo, excluir um usuário, adicionar um grupo, etc.) enquantoread
,search
,compare
ewrite
são mais de nível de atributo: você pode escrever parauserCertificate
mas não leruserPassword
.--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
NotaAs 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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
- Permissões existentes. Para detalhes sobre as permissões, consulte Gerenciando as permissões IdM no CLI.
Procedimento
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"
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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
- Privilégios existentes. Para detalhes sobre privilégios, veja Managing IdM privileges in the CLI.
Procedimento
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
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 ----------------------------
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.); conjuntossubtree
etarget filter
-
memberof
: membros de um grupo; estabelece umtarget filter
-
targetgroup
: concede acesso para modificar um grupo específico (como a concessão dos direitos de administrar a adesão ao grupo); estabelece umtarget
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.
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.
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
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.
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.
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.
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
Papel | Privilégio | Descriçã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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
Procedimento
Para adicionar uma nova permissão, abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Permissions:
A lista de permissões é aberta: Clique no botão Add no topo da lista de permissões:
O formulário Add Permission é aberto. Especifique o nome da nova permissão e defina suas propriedades de acordo:
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
NotaNã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.
- Escolha os direitos a conceder com esta permissão em Granted rights.
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.
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.
ImportanteSe você não definir nenhum atributo para a permissão, então as permissões incluem todos os atributos por padrão.
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.
- 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.
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.
NotaAs 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):
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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
- Permissões existentes. Para obter detalhes sobre as permissões, consulte Gerenciando permissões na IDM Web UI.
Procedimento
Para adicionar um novo privilégio, abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Privileges:
A lista de privilégios é aberta. Clique no botão Add no topo da lista de privilégios:
O formulário Add Privilege é aberto. Digite o nome e uma descrição do privilégio:
- 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.
- 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.
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:
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:
- Confirme clicando no botão Add.
- 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.
- 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
- Privilégios de administrador para administrar a IdM ou o papel User Administrator.
- Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
- Privilégios existentes. Para detalhes sobre privilégios, veja Managing privileges in the IdM Web UI.
Procedimento
Para adicionar um novo papel, abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Roles:
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.
O formulário Add Role é aberto. Digite o nome da função e uma descrição:
- 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.
- 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.
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).
Na janela que se abre, selecione os membros à esquerda e use o botão > para movê-los para a coluna Prospective.
Na parte superior da aba Privileges, clique em Add.
Selecione os privilégios à esquerda e use o botão > para movê-los para a coluna Prospective.
- Clique no botão Add para salvar.
- 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.
- 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:
- Vistas de identificação
- Potencial impacto negativo das visões de identificação no desempenho da SSSD
- Atributos que uma vista de identificação pode anular
- Obtendo ajuda para os comandos de visualização de identificação
- Usando uma visão ID para substituir o nome de login de um usuário IdM em um host específico
- Modificando uma visão de ID de IdM
- Adicionando uma visualização ID para substituir um diretório pessoal de usuário IdM em um cliente IdM
- Aplicando uma visão de identificação a um grupo anfitrião da IdM
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, alterarfallback_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.
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
)
-
Nome de Login (
- Atributos do grupo
-
Nome do grupo (
cn
) -
Número GID do grupo (
gidNumber
)
-
Nome do grupo (
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
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
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.
NotaO 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 comandoipa idoverrideuser-add-cert
em seu lugar:$ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
-
Digite o comando
-
Opcional: Usando o comando
ipa idoverrideuser-mod
, você pode especificar novos valores de atributos para uma substituição de usuário existente. Aplique
example_for_host1
para o anfitriãohost1.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 ---------------------------------------------
NotaO 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.
Para aplicar a nova configuração ao sistema host1.idm.example.com imediatamente:
SSH para o sistema como raiz:
$ ssh root@host1 Password:
Limpar o cache SSSD:
root@host1 ~]# sss_cache -E
- 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:
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 ~]$
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
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/
Alterar a propriedade do diretório:
[root@host1 /]# chown idm_user:idm_user /home/user_1234/
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.
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
.-
Digite o comando
Para aplicar a nova configuração ao sistema host1.idm.example.com imediatamente:
SSH para o sistema como raiz:
$ ssh root@host1 Password:
Limpar o cache SSSD:
root@host1 ~]# sss_cache -E
- Reinicie o daemon SSSD:
root@host1 ~]# systemctl restart sssd
Etapas de verificação
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 ~]$
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
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/
Alterar a propriedade do diretório:
[root@host1 /]# chown idm_user:idm_user /home/user_1234/
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
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/
-
Digite o comando
Aplique
example_for_host1
para o anfitriãohost1.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 ---------------------------------------------
NotaO 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.
Para aplicar a nova configuração ao sistema host1.idm.example.com imediatamente:
SSH para o sistema como raiz:
$ ssh root@host1 Password:
Limpar o cache SSSD:
root@host1 ~]# sss_cache -E
- Reinicie o daemon SSSD:
root@host1 ~]# systemctl restart sssd
Etapas de verificação
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 /]$
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:
- Como criar um grupo anfitrião e adicionar anfitriões a ele.
- Como aplicar uma visão de identificação ao grupo anfitrião.
- Como adicionar um novo anfitrião ao grupo anfitrião e aplicar a visão de identificação ao novo anfitrião.
Pré-requisitos
- Certifique-se de que a visão de identificação que você deseja aplicar ao grupo anfitrião exista na IdM. Por exemplo, para criar uma visualização ID para substituir o nome de login de um usuário IdM em um cliente IdM específico, veja Utilizando uma visualização ID para substituir o nome de login de um usuário IdM em um host específico.
Procedimento
Criar um grupo anfitrião e adicionar anfitriões a ele:
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
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 -------------------------
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 ---------------------------------------------
Adicione um novo anfitrião ao grupo anfitrião e aplique a visão de identificação ao novo anfitrião:
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 -------------------------
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.
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.
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.
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.
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.
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.
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.
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
- Optional. Se você estiver recuperando uma faixa de ID de DNA a partir de uma réplica não funcional, primeiro encontre a faixa de ID usando os comandos descritos em Exibindo faixas de ID de DNA atualmente atribuídas.
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
- Você pode verificar se as novas faixas de DNA são definidas corretamente usando os comandos descritos em Exibição das faixas de ID de DNA atualmente atribuídas.
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:
- Preparando o Gerenciamento de Identidade (IdM ) para usar um sistema de provisionamento externo para adicionar usuários de palco ao IdM.
- Criação de um script para mover os usuários adicionados pelo sistema de provisionamento externo do estágio para usuários ativos.
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
Entrar como administrador da IdM:
$ parentes admin
Criar um usuário chamado provisionator com os privilégios de adicionar usuários de palco.
- Adicionar a conta de usuário do provisionador:
$ ipa usuário-adicionador de provisão --first=provisionamento --last=conta --palavra-palavra
Conceder ao usuário do provisionador os privilégios necessários.
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"
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"
Adicionar o usuário provisionador à função:
$ ipa role-add-member --usuários=provisionador {\i1}"System Provisioning
- 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 [...]
Criar um usuário, activator, com os privilégios de gerenciar contas de usuário.
Adicionar a conta do usuário ativador:
$ ipa ativador-adicionado pelo usuário --first=ativação --last=conta --palavra-palavra
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
Criar um grupo de usuários para contas de aplicação:
Contas de aplicação de $ ipa group-add
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
(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 [...]
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}
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:
- Para detalhes sobre como adicionar novos usuários, consulte Gerenciando contas de usuários usando a linha de comando.
- Para detalhes sobre a concessão aos usuários dos privilégios necessários para gerenciar outras contas de usuários, consulte Delegando permissões sobre os usuários.
- Para detalhes sobre o gerenciamento das políticas de senhas da IdM, consulte Definindo as políticas de senhas da IdM.
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.
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
- As contas provisionator e activator existem na IdM. Para detalhes, consulte Preparação de contas IdM para ativação automática de contas de usuários em estágio.
- Você tem privilégios de raiz no servidor IdM no qual você está executando o procedimento.
- Você está logado como administrador da IdM.
- Você confia em seu sistema de provisionamento externo.
Procedimento
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.
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
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
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
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
Recarregar a nova configuração:
# systemctl daemon-reload
Habilitar
ipa-activate-all.timer
:# systemctl habilita ipa-activate-all.timer
Iniciar
ipa-activate-all.timer
:# systemctl start ipa-activate-all.timer
(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
-
O
Procedimento
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
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
Use o protocolo
SSH
para conectar-se ao servidor da IdM como provisionator:$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
No servidor da IdM, obtenha o ticket de concessão de bilhetes Kerberos (TGT) para a conta do provisionador:
[provisionador@servidor ~]$ parente provisionador
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
-
O
Procedimento
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 ~]$
Obter o TGT da conta provisionator, um usuário IdM com um papel para adicionar novos usuários em palco:
Provisor de parentesco
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.
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
Digite add como o tipo de mudança que você está realizando:
tipo de mudança: adicionar
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.
Entre no site
uid
do usuário:uid: usuário de palco
Entre no site
cn
do usuário:cn: Babs Jensen
Digite o sobrenome do usuário:
sn: Jensen
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"
- 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
-
Note que o usuário é explicitamente desabilitado pelo atributo
nsaccountlock
.
-
Note que o usuário é explicitamente desabilitado pelo atributo
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 permanecenssAccountLock: 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
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
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
Faça o login como um usuário IdM com um papel para preservar os usuários:
$ parentes admin
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.
Entre no site
dn
do usuário que você deseja preservar:dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Digite modrdn como o tipo de mudança que você deseja realizar:
tipo de mudança: modrdn
Especifique o newrdn para o usuário:
newrdn: uid=usuário1
Indicar que você deseja preservar o usuário:
deleteoldrdn: 0
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.
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"
- 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 comando
ipa 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 grupoadmins
. A funçãoHost 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 deEnrollment Administrator
, que fornece o privilégio deHost 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ção Usuário Anfitriã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)
-
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 é
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ário Anfitriã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ção | Quais 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)? |
---|---|---|---|
| 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 |
| 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. |
|
| O anfitrião deve ter uma entrada na IdM. | Quando você quiser que o anfitrião temporariamente incapacitado torne-se ativo novamente. |
|
| 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. |
|
| O anfitrião deve ter uma entrada na IdM. | Quando você quiser remover o anfitrião do reino da IdM permanentemente. |
|
Tabela 27.4. Operações de hospedagem parte 2
Ação | Em 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? |
---|---|---|
|
No caso de uma inscrição em duas etapas: | 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. |
| 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. |
| 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. |
| O anfitrião a ser reconduzido. As credenciais LDAP precisam ser fornecidas. | Uma nova chave Kerberos é gerada para o anfitrião, substituindo a anterior. |
| 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 |
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
Note que a guia IdM Web UI Identity
→ Hosts
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 UI | Opção de Linha de Comando | Descrição |
---|---|---|
Descrição |
| Uma descrição do anfitrião. |
Localidade |
| A localização geográfica do anfitrião. |
Localização |
| A localização física do host, tal como seu rack do centro de dados. |
Plataforma |
| O hardware ou arquitetura do host. |
Sistema operacional |
| O sistema operacional e a versão para o host. |
Endereço MAC |
|
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 |
Chaves públicas SSH |
| 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) |
|
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 |
Definir senha única |
| Esta opção define uma senha para o anfitrião que pode ser usada na inscrição em massa. |
- |
| Esta opção gera uma senha aleatória para ser usada na inscrição em massa. |
- |
| Uma bolha de certificado para o anfitrião. |
- |
| 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 comandoipa 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.
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.
- Re-criar a máquina do cliente com o mesmo nome de host.
Execute o comando
ipa-client-install --force-join
na máquina do cliente:# ipa-client-install --force-join
O roteiro solicita um usuário cuja identidade será usada para re-inscrever o cliente. Este poderia ser, por exemplo, um usuário
hostadmin
com a função de Administrador de Inscrição:User authorized to enroll computers:
hostadmin
Password forhostadmin
@EXAMPLE.COM
:
Recursos adicionais
- Para um procedimento mais detalhado sobre a inscrição de clientes usando as credenciais de um usuário autorizado, consulte Instalando um cliente usando as credenciais de usuário: Instalação interativa em Installing Identity Management.
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.
- Re-criar a máquina do cliente com o mesmo nome de host.
-
Copie o arquivo keytab do local de backup para o diretório
/etc/
na máquina do cliente recriada. Use o utilitário
ipa-client-install
para reinscrever o cliente, e especifique a localização da tabela de chaves com a opção--keytab
:# ipa-client-install --keytab /etc/krb5.keytab
NotaA tabela de chaves especificada na opção
--keytab
é usada somente quando se autentica para iniciar a inscrição. Durante o recadastramento, a IdM gera uma nova tabela de chaves para o cliente.
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.
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:
- Preparando o anfitrião. Para detalhes, veja Seção 27.8.1, “Pré-requisitos”
- Desinstalando o cliente IdM do anfitrião. Para detalhes, veja Seção 27.8.2, “Desinstalando um cliente de Gerenciamento de Identidade”
- Renomeando o anfitrião. Para detalhes, veja Seção 27.8.3, “Renomeando o sistema hospedeiro”
- 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”
- 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.com
determinar a localização das fichas-chave correspondentes noold-client-name.example.com
sistema:# find / -name "*.keytab"
Cada serviço no sistema do cliente tem um Kerberos principal no formulário service_name/host_name@REALM, como por exemplo
ldap/old-client-name.example.com@EXAMPLE.COM
.Identificar todos os grupos anfitriões aos quais a máquina pertence.
# ipa hostgroup-find old-client-name.example.com
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
Execute o comando
ipa-client-install --uninstall
:[root@client]# ipa-client-install --uninstall
Remover manualmente do servidor as entradas DNS para o host cliente:
[root@server]# ipa dnsrecord-del Record name: old-client-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"
Para cada chaveta identificada que não seja
/etc/krb5.keytab
, remova os antigos diretores:[root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
Em um servidor IdM, remova a entrada do host. 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
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
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
- 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.
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
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 comando
ipa 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 grupoadmins
. A funçãoHost 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 deEnrollment Administrator
, que fornece o privilégio deHost 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ção Usuário Anfitriã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)
-
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 é
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ário Anfitriã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
Note que a guia IdM Web UI Identity
→ Hosts
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 UI | Opção de Linha de Comando | Descrição |
---|---|---|
Descrição |
| Uma descrição do anfitrião. |
Localidade |
| A localização geográfica do anfitrião. |
Localização |
| A localização física do host, tal como seu rack do centro de dados. |
Plataforma |
| O hardware ou arquitetura do host. |
Sistema operacional |
| O sistema operacional e a versão para o host. |
Endereço MAC |
|
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 |
Chaves públicas SSH |
| 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) |
|
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 |
Definir senha única |
| Esta opção define uma senha para o anfitrião que pode ser usada na inscrição em massa. |
- |
| Esta opção gera uma senha aleatória para ser usada na inscrição em massa. |
- |
| Uma bolha de certificado para o anfitrião. |
- |
| 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
-
Abra a guia
Identity
, e selecione a subguiaHosts
. Clique em Adicionar no topo da lista de anfitriões.
Figura 28.1. Adicionando entradas de anfitrião
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
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.
NotaSelecione a caixa de seleção
Force
se você quiser pular a verificação se o host é resolúvel via DNS.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
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:
-
Garantir a presença de entradas de anfitriões IdM que só são definidas por seus
FQDNs
- Garantindo a presença de entradas do host IdM com endereços IP
- Garantir a presença de múltiplas entradas no host IdM com senhas aleatórias
- Assegurar a presença de um host IdM com múltiplos endereços IP
- Garantindo a ausência de entradas do host IdM
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.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
Execute o livro de brincadeiras:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
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
Faça o login em seu servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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âmetroip_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
Execute o livro de brincadeiras:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
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
Faça o login em seu servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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 eupdate_password
está limitado aon_create
, adicione as opçõesrandom: yes
eforce: 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
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"}}}
Para implantar os anfitriões como clientes IdM usando senhas aleatórias e únicas (OTPs), veja Opções de autorização para inscrição de clientes IdM usando um livro de exercícios ou Instalação de um cliente usando uma senha única: Instalação interativa.
Etapas de verificação
Faça o login em seu servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
Crie um arquivo de livro de brincar possível. Especifique, como o
name
da variávelipahost
, ofully-qualified domain name
(FQDN) do anfitrião cuja presença na IdM você quer garantir. Especifique cada um dos múltiplos valores IPv4 e IPv6ip_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
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
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
Faça o login em seu servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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çãoupdatedns: 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
Execute o livro de brincadeiras:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-absent.yml
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
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
- 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.
Procedimento
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
- 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.
Procedimento
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
- 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.
Procedimento
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" --------------------------
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
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}
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
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 -------------------------
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
-
Optional. Use o comando
ipa hostgroup-find
para encontrar anfitriões e grupos anfitriões. 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 -------------------------
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 -------------------------
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
-
Optional. Use o comando
ipa hostgroup-find
para encontrar anfitriões e grupos anfitriões. 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 ---------------------------
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 ---------------------------
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
- 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.
Procedimento
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.
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.
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.
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
- 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.
Procedimento
- Clique em Identity → Groups, e selecione a aba Host Groups.
- Clique em Add. O diálogo Add host group aparece.
- Fornecer as informações sobre o grupo: nome (obrigatório) e descrição (opcional).
Clique em Add para confirmar.
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
- 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.
Procedimento
- Clique em Identity → Groups e selecione a guia Host Groups.
- Selecione o grupo hospedeiro IdM para remover, e clique em Delete. Aparece um diálogo de confirmação.
Clique em Delete para confirmar
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
- 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.
Procedimento
- Clique em Identity → Groups e selecione a guia Host Groups.
- Clique no nome do grupo ao qual você deseja adicionar membros.
- Clique na guia Hosts ou Host groups, dependendo do tipo de membros que você deseja adicionar. O diálogo correspondente aparece.
- Selecione os anfitriões ou grupos de anfitriões para adicionar, e clique no botão > seta para movê-los para a coluna Prospective.
Clique em Add para confirmar.
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
- 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.
Procedimento
- Clique em Identity → Groups e selecione a guia Host Groups.
- Clique no nome do grupo do qual você deseja remover membros.
- Clique na guia Hosts ou Host groups, dependendo do tipo de membros que você deseja remover.
- Selecione a caixa de seleção ao lado do membro que você deseja remover.
Clique em Excluir. Aparece um diálogo de confirmação.
- 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
Clique em Identity → Groups e selecione a guia Host Groups.
- Clique no nome do grupo ao qual você deseja adicionar gerentes membros.
- Clique na guia gerentes membros User Groups ou Users, dependendo do tipo de gerentes membros que você deseja adicionar. O diálogo correspondente aparece.
Clique em Add.
- Selecione os usuários ou grupos de usuários para adicionar, e clique no botão > seta para movê-los para a coluna Prospective.
- Clique em Add para confirmar.
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.
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
Clique em Identity → Groups e selecione a guia Host Groups.
- Clique no nome do grupo do qual você deseja remover os gerentes membros.
- Clique na guia gerentes membros User Groups ou Users, dependendo do tipo de gerentes membros que você deseja remover. O diálogo correspondente aparece.
- Selecione o usuário ou grupos de usuários a remover e clique em Delete.
Clique em Delete para confirmar.
NotaApó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.
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):
- Garantindo a presença de grupos anfitriões da IdM
- Assegurando a presença de anfitriões em grupos anfitriões da IdM
- Aninhamento de grupos hospedeiros IdM
- Assegurar a presença de gerentes membros nos grupos anfitriões da IdM
- Assegurando a ausência de anfitriões de grupos anfitriões da IdM
- Assegurar a ausência de grupos anfitriões aninhados de grupos anfitriões da IdM
- Assegurando a ausência dos gerentes membros dos grupos anfitriões da 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.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
nele com a lista de servidores IdM a serem alvo:[ipaserver] server.idm.example.com
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á.
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
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicite um bilhete Kerberos para administração:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
- Você sabe a senha do administrador da IdM.
- Você instalou o pacote ansible-freeipa no controlador Ansible.
- Os anfitriões que você deseja mencionar em seu livro de jogo Ansible playbook existem na IdM. Para detalhes, consulte Assegurando a presença de uma entrada de anfitrião IdM usando Livros de Brinquedos Ansíveis.
- Os grupos anfitriões a que você faz referência a partir do arquivo Ansible playbook foram adicionados à IdM. Para detalhes, veja Assegurando a presença de grupos hospedeiros IdM usando os playbooks Ansible playbooks.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
nele com a lista de servidores IdM a serem alvo:[ipaserver] server.idm.example.com
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ávelipahostgroup
. Especificar o nome do anfitrião com o parâmetrohost
da variávelipahostgroup
. 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.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
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicite um bilhete Kerberos para administração:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
- Você sabe a senha do administrador da IdM.
- Você instalou o pacote ansible-freeipa no controlador Ansible.
- Os grupos anfitriões a que você faz referência a partir do arquivo Ansible playbook existem na IdM. Para detalhes, veja Assegurando a presença de grupos hospedeiros da IdM usando Livros de Jogadas Ansíveis.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
nele com a lista de servidores IdM a serem alvo:[ipaserver] server.idm.example.com
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ávelname
. Especificar o nome do grupo anfitrião aninhado A com a variávelhostgroup
. 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.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
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicite um bilhete Kerberos para administração:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
:
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
- Você sabe a senha do administrador da IdM.
- Você instalou o pacote ansible-freeipa no controlador Ansible.
- Os anfitriões que você deseja mencionar em seu livro de jogo Ansible playbook existem na IdM. Para detalhes, consulte Assegurando a presença de uma entrada de anfitrião IdM usando Livros de Brinquedos Ansíveis.
- Os grupos anfitriões a que você faz referência a partir do arquivo Ansible playbook existem na IdM. Para detalhes, veja Assegurando a presença de grupos hospedeiros da IdM usando Livros de Jogadas Ansíveis.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
nele com a lista de servidores IdM a serem alvo:[ipaserver] server.idm.example.com
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ávelipahostgroup
. Especificar o nome do anfitrião cuja ausência do grupo anfitrião você deseja garantir usando o parâmetrohost
da variávelipahostgroup
. 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.
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
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicite um bilhete Kerberos para administração:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
- Você sabe a senha do administrador da IdM.
- Você instalou o pacote ansible-freeipa no controlador Ansible.
- Os grupos anfitriões a que você faz referência a partir do arquivo Ansible playbook existem na IdM. Para detalhes, veja Assegurando a presença de grupos hospedeiros da IdM usando Livros de Jogadas Ansíveis.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
nele com a lista de servidores IdM a serem alvo:[ipaserver] server.idm.example.com
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ávelname
. Especifique o nome do grupo de anfitrião aninhado com a variávelhostgroup
. 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.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
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicite um bilhete Kerberos para administração:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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.
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
nele com a lista de servidores IdM a serem alvo:[ipaserver] server.idm.example.com
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.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
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicite um bilhete Kerberos para administração:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
:
Acesse
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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:
- O papel da IdM KDC
- Tipos de política de bilhetes da IdM Kerberos
- Indicadores de autenticação Kerberos
- Aplicação de indicadores de autenticação para um serviço IdM
- Configurando a política global do ciclo de vida dos bilhetes
- Configuração de políticas de bilhetes globais por indicador de autenticação
- Configurando a política padrão de bilhetes para um usuário
- Configuração de políticas de bilhetes indicadores de autenticação individuais para um usuário
-
Opções de indicadores de autenticação para o comando
krbtpolicy-mod
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 comoadmin@EXAMPLE.COM
-
Para serviços:
service/fully-qualified-hostname@REALM
, tais comohttp/master.example.com@EXAMPLE.COM
-
Para anfitriões:
host/fully-qualified-hostname@REALM
, tais comohost/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.
-
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. - 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.
- 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.
- Com o TGT, o cliente solicita um service ticket do KDC para se comunicar com um serviço Kerberized em um host alvo.
- 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.
- O KDC emite ao cliente um service ticket.
- 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 aplicativotestservice
emclient2.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:
- Para configurar diferentes valores globais do ciclo de vida do bilhete para cada indicador de autenticação, consulte Configurando políticas globais de bilhetes por indicador de autenticação.
- Para definir os valores do ciclo de vida dos bilhetes para um único usuário que se aplicam independentemente do método de autenticação utilizado, consulte Configurando a política padrão de bilhetes para um usuário.
- Para definir valores individuais do ciclo de vida do bilhete para cada indicador de autenticação que só se aplicam a um único usuário, consulte Configurando políticas de bilhetes indicadores de autenticação individuais para um usuário.
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
- Para associar um serviço IdM com indicadores de autenticação, consulte Aplicando indicadores de autenticação para um serviço IdM.
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
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çãotestservice
que roda no hostclient.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
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
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
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
- Você criou uma entrada de serviço IdM para um serviço que funciona em um host IdM. Veja Criando uma entrada de serviço IdM e sua tabela chave Kerberos.
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
valorAutenticaçã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 hostclient.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
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
- Para testar a solicitação de uma senha de serviço para um serviço IdM, veja Recuperação de uma senha de serviço Kerberos para um serviço IdM.
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
- Se o serviço com o qual você está trabalhando não é um serviço interno da IdM, você criou uma entrada correspondente em IdM service para ele. Veja Criando uma entrada de serviço IdM e sua tabela de chaves Kerberos.
- Você tem um bilhete de passagem de Kerberos (TGT).
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
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
- Para mais informações sobre os indicadores de autenticação Kerberos, ver Seção 33.3, “Indicadores de autenticação Kerberos”.
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
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).
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
- Para ajustar a política padrão de bilhetes para um único usuário, consulte Configurando a política padrão de bilhetes para um usuário.
- Para configurar políticas de bilhetes individuais para cada indicador de autenticação para um único usuário, consulte Configurando políticas de bilhetes indicadores de autenticação individuais para um usuário.
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
eMax renew
.
Recursos adicionais
-
Para uma lista de opções de indicadores de autenticação para o comando
ipa krbtpolicy-mod
, consulte Opções de indicadores de autenticação para o comandokrbtpolicy-mod
. - Para ajustar a política padrão de bilhetes para um único usuário, consulte Configurando a política padrão de bilhetes para um usuário.
- Para configurar políticas de bilhetes individuais para cada indicador de autenticação para um único usuário, consulte Configurando políticas de bilhetes indicadores de autenticação individuais para um usuário.
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
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
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
- Para ajustar a política global de bilhetes para todos os usuários, consulte Configurando a política global de ciclo de vida dos bilhetes.
- Para configurar diferentes políticas de bilhetes padrão por indicador de autenticação, consulte Configurando políticas de bilhetes globais por indicador de autenticação.
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
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
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
-
Para uma lista de opções de indicadores de autenticação para o comando
ipa krbtpolicy-mod
, consulte Opções de indicadores de autenticação para o comandokrbtpolicy-mod
. - Para ajustar a política padrão de bilhetes para um único usuário, consulte Configurando a política padrão de bilhetes para um usuário.
- Para ajustar a política global de bilhetes para todos os usuários, consulte Configurando a política global de ciclo de vida dos bilhetes.
- Para configurar diferentes políticas de bilhetes globais por indicador de autenticação, consulte Configurando políticas de bilhetes globais por indicador de autenticação.
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ção | Argumento para uma vida útil máxima | Argumento para a idade máxima de renovação |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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
Atributo | Explicação | Exemplo |
---|---|---|
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:
*
* | Classes de caracteres = 0
O número padrão de classes necessárias é 0. Para configurar o número, execute o comando 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 |
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 | Duração do Lockout = 600 Os usuários com contas bloqueadas não podem fazer login por 10 minutos. |
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.
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
Crie um arquivo de inventário, por exemplo
inventory.file
, e defina oFQDN
de seu servidor IdM na seção[ipaserver]
:[ipaserver] server.idm.example.com
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.
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.
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.
- O que é a ferramenta de Notificação de Senha Vitalícia
- Instalando a ferramenta de notificação de senha expirada
- Executar a ferramenta EPN para enviar e-mails aos usuários cujas senhas estão expirando
- Habilitação do ipa-epn.timer para enviar um e-mail a todos os usuários cujas senhas estão expirando
- Modificando o modelo de e-mail de notificação de senha expirada
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.
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.
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
-
O pacote
ipa-client-epn
está instalado. Veja Instalando a ferramenta Notificação de Senha Vitalícia. -
Personalize o modelo de e-mail
ipa-epn
, se necessário. Veja Modificando o modelo de e-mail de Notificação de Senha Vitalícia.
Procedimento
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
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
Configure seu servidor SMTP e porta:
smtp_server = localhost smtp_port = 25
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
-
Salvar o arquivo
/etc/ipa/epn.conf
. 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
NotaSe 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.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
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
NotaSe 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
-
O pacote
ipa-client-epn
está instalado. Veja Instalando a ferramenta Notificação de Senha Vitalícia -
Personalize o modelo de e-mail
ipa-epn
, se necessário. Veja Modificando o modelo de e-mail de Notificação de Senha Vitalícia
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
Abra o modelo de mensagem EPN:
# vi /etc/ipa/epn/expire_msg.template
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
- 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
Adicione o comando
/usr/sbin/reboot
ao banco de dados do IdM desudo
comandos:- Navegue para Policy → Sudo → Sudo Commands.
- Clique em Add no canto superior direito para abrir a caixa de diálogo Add sudo command.
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
- Clique em Add.
Use o novo comando
sudo
para criar uma regra sudo para permitir idm_user para reiniciar a máquina idmclient:- Navegue para Policy → Sudo → Sudo rules.
- Clique em Add no canto superior direito para abrir a caixa de diálogo Add sudo rule.
-
Digite o nome da regra
sudo
: idm_user_reboot. - Clique em Add and Edit.
Especifique o usuário:
- Na seção Who, verifique o botão de rádio Specified Users and Groups.
- 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".
- 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.
- Clique em Add.
Especifique o anfitrião:
- Na seção Access this host, verifique o botão de rádio Specified Hosts and Groups.
- 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".
- 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.
- Clique em Add.
Especifique os comandos:
- 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.
- 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".
-
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. Clique em Add para retornar à página idm_sudo_reboot.
Figura 36.2. Adicionando a regra do sudo IdM
- 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.
- Acesse idmclient como idm_user.
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
- Você instalou o pacote ansible-freeipa no controlador Ansible.
- Você sabe a senha do administrador da IdM.
- Você garantiu a presença de uma conta de usuário para idm_user na 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.
-
Não existe uma conta idm_user local em idmclient. O usuário idm_user não está listado no arquivo
/etc/passwd
em idmclient.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaservers
no mesmo:[ipaservers] server.idm.example.com
Adicione um ou mais comandos em
sudo
: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 desudo
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
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
Criar uma regra
sudo
que faça referência aos comandos:Criar um livro de jogo
ensure-sudorule-for-idmuser-on-idmclient-is-present.yml
que utiliza o comandosudo
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
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.
- Acesse idmclient como idm_user.
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
- O pacote ansible-freeipa é instalado no controlador Ansible.
- Você sabe a senha do administrador da IdM.
- Os usuários e grupos de usuários que você deseja usar para sua regra HBAC existem na IdM. Consulte Gerenciando contas de usuários usando Livros de Jogadas Ansíveis e Garantindo a presença de grupos e membros de grupos IdM usando Livros de Jogadas Ansíveis para maiores detalhes.
- Os anfitriões e grupos anfitriões para os quais você deseja aplicar sua regra HBAC existem na IdM. Veja Gerenciamento de anfitriões usando Livros didáticos Ansíveis e Gerenciamento de grupos anfitriões usando Livros didáticos Ansíveis para maiores detalhes.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
, e definiripaserver
no mesmo:[ipaserver] server.idm.example.com
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
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
- Entrar na IDM Web UI como administrador.
- Navegue para Policy → Host-Based-Access-Control → HBAC Test.
- Na aba Who, selecione idm_user.
- Na guia Accessing, selecione client.idm.example.com.
- Na guia Via service, selecione sshd.
- Na aba Rules, selecione login.
- 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 CA | Descrição | Use | Links úteis |
---|---|---|---|
O | 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 |
As sub-CAs de IdM são CAs às quais a CA | 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
- Para mais detalhes sobre as configurações CA suportadas do servidor IdM, consulte Planejamento de seus serviços CA.
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 |
| Sim | Sim |
| Opcional | Sim |
| Opcional | Sim |
| Simétrico | Assimétrico |
| 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:
- Solicitação de novos certificados para um usuário, host ou serviço usando a IDM Web UI.
Solicitação de novos certificados para um usuário, host ou serviço da IdM CA usando a IdM CLI:
Solicitação de novos certificados para um usuário, host ou serviço da IdM CA usando certutil
-
Para um exemplo específico de solicitação de um novo certificado de usuário da IdM CA usando o utilitário
certutil
e exportando-o para um cliente IdM, veja Solicitação de um novo certificado de usuário e exportação para o cliente.
-
Para um exemplo específico de solicitação de um novo certificado de usuário da IdM CA usando o utilitário
- Solicitação de novos certificados para um usuário, host ou serviço da IdM CA usando o openssl
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
Sua implantação de IdM contém uma CA integrada:
- Para informações sobre como planejar seus serviços de CA na IdM, consulte Planejando seus serviços de CA.
- Para informações sobre como instalar um servidor IdM com DNS integrado e CA integrada como a CA raiz, consulte Instalação de um servidor IdM: Com DNS integrado, com uma CA integrada como a CA raiz
- Para informações sobre como instalar um servidor IdM com DNS integrado e uma CA externa como a CA raiz, veja Instalando um servidor IdM: Com DNS integrado, com uma CA externa como a CA raiz
- Para informações sobre como instalar um servidor IdM sem DNS integrado e com uma CA integrada como a CA raiz, consulte Instalando um servidor IdM: Sem DNS integrado, com uma CA integrada como a CA raiz.
[Opcional] Sua implantação IdM suporta usuários que se autenticam com um certificado:
- Para informações sobre como configurar sua implantação IdM para suportar a autenticação do usuário com um certificado armazenado no sistema de arquivos do cliente IdM, consulte Configurando a autenticação com um certificado armazenado na área de trabalho de um cliente IdM.
- Para informações sobre como configurar sua implantação IdM para suportar a autenticação do usuário com um certificado armazenado em um cartão inteligente inserido em um cliente IdM, veja
- Para informações sobre como configurar sua implantação de IdM para suportar a autenticação do usuário com cartões inteligentes emitidos por um sistema de certificados do Active Directory, veja
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
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
-
Na guia
Identity
, selecione a subguiaUsers
,Hosts
, ouServices
. 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
- Clique Ações → Novo certificado.
- Opcional: Selecione a CA emissora e a identificação do perfil.
-
Siga as instruções para usar o utilitário de linha de comando (CLI)
certutil
na tela. - 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
.
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
Criar um diretório temporário para o banco de dados de certificados:
# mkdir ~/certdb/
Criar um novo banco de dados de certificados temporários, por exemplo:
# certutil -N -d ~/certdb/
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
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
-
Para mais informações sobre o comando
ipa cert-request
, veja a saída do comandoipa cert-request --help
. - Para mais informações sobre a criação de um perfil de certificado personalizado, consulte Criação e gerenciamento de perfis de certificado em Gerenciamento de Identidade.
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
.
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
- 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.
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
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
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
-
Para mais informações sobre o comando
ipa cert-request
, veja a saída do comandoipa cert-request --help
. - Para mais informações sobre a criação de um perfil de certificado personalizado, consulte Criação e gerenciamento de perfis de certificado em Gerenciamento de Identidade.
39.4. Recursos adicionais
- Para informações sobre como revogar certificados usando a IdM CA, consulte Revogação de certificados com as CAs IdM integradas.
- Para informações sobre como restaurar certificados usando o IdM CA, consulte Restauração de certificados com o IdM CAs integrado.
- Para informações sobre como restringir um pedido para confiar somente em certificados que foram emitidos por uma sub-CA da IdM, consulte Restrição de um pedido para confiar somente em um subconjunto de certificados.
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:
- Você está carregando um certificado externo em um perfil de usuário. Para maiores detalhes, veja Seção 40.2, “Conversão de um certificado externo para carregar em uma conta de usuário IdM”.
- Você está usando um certificado CA externo ao configurar o servidor IdM para autenticação de Cartão Smart Card ou ao configurar o cliente IdM para autenticação de Cartão Smart Card para que os usuários possam autenticar no IdM usando Cartões Smart Card com certificados que foram emitidos pela autoridade de certificado externa.
- Você está exportando um certificado de um banco de dados NSS para um formato pkcs #12 que inclui tanto o certificado quanto a chave privada. Para maiores detalhes, veja Seção 40.3.1, “Exportação de um certificado e chave privada de um banco de dados NSS para um arquivo PKCS #12”.
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ção | Legível para humanos | Extensões de nomes de arquivos comuns | Exemplo 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 comandokinit -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 comandokinit -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 arquivoPEM
tenha sido convertido para o formatoUNIX
. Para converter um arquivo, use o utilitáriodos2unix
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
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árioopenssl 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:
Obter as credenciais do administrador:
$ kinit admin
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áriosed
antes de adicionar a string ao comandoipa 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...
NotaVocê não pode passar um arquivo
PEM
contendo o certificado como entrada para o comandoipa 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".
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
Usando o
CLI
, converta o certificado para o formatoPEM
: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árioopenssl 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:
-
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 obase64
são aceitos pela IDM web UI. - Na IDM web UI, faça o login como oficial de segurança.
-
Ir para
Identity
→Users
→some_user
. -
Clique em
Add
ao lado deCertificates
. - Colar o conteúdo do certificado no formato PEM na janela que se abre.
-
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:
- O certificado está localizado em um banco de dados do NSS. Para obter detalhes sobre como proceder nesta situação, consulte Seção 40.3.1, “Exportação de um certificado e chave privada de um banco de dados NSS para um arquivo PKCS #12”.
-
O certificado e a chave privada estão em dois arquivos
PEM
separados. Para detalhes sobre como proceder nesta situação, veja Seção 40.3.2, “Combinação de arquivos PEM certificados e chaves privadas em um arquivo PKCS #12”.
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
Use o comando
pk12util
para exportar o certificado do banco de dados do NSS para o formatoPKCS12
. Por exemplo, para exportar o certificado com o nicknamesome_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 SUCCESSFULDefina 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 emcertfile.key
em um arquivocertfile.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
Comando | Formatos aceitáveis | Notas |
---|---|---|
| certificado PEM base64 | |
| Certificado PEM e DER; cadeia de certificados PKCS#7; PKCS#8 e chave privada bruta; certificado PKCS#12 e chave privada | |
| DER; PEM; PKCS#7 | |
| Certificado PEM e DER; cadeia de certificados PKCS#7 | |
| Certificado PEM e DER; cadeia de certificados PKCS#7 | |
| N/A |
Cria o arquivo PEM-encoded |
| N/A |
Cria o arquivo PEM-encoded |
| N/A |
Cria o arquivo |
| N/A |
Cria o arquivo |
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.
- O que é um perfil de certificado
- Criação de um perfil de certificado
- O que é uma lista de controle de acesso CA
- Definição de uma ACL CA para controlar o acesso aos perfis de certificado
- Usando perfis de certificados e ACLs CA para emitir certificados
- Modificando um perfil de certificado
- Parâmetros de configuração do perfil do certificado
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 comandoipa 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
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
Abra o arquivo de configuração de perfil recém-criado em um editor de texto.
$ vi smime.cfg
Mude o
Profile ID
para um nome que reflita o uso do perfil, por exemplosmime
.NotaQuando você estiver importando um perfil recém-criado, o campo
profileId
, se presente, deve corresponder ao ID especificado na linha de comando.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
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 comandoipa 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 comandoipa 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
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
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
Acrescente o
smime_user
ao gruposmime_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 -------------------------
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
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 -------------------------
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 comandoipa 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.
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
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'
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 comandoipa help user-show
. -
Para mais detalhes sobre o comando
ipa cert-request
, consulte o comandoipa 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
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 --------------------------
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
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.
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 comandoipa 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âmetro | Descrição |
---|---|
desc |
Uma descrição em texto livre do perfil do certificado, que é mostrada na página final das entidades. Por exemplo, |
habilitar |
Permite que o perfil seja acessível através da página das entidades finais. Por exemplo, |
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, |
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
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, |
input.list |
Lista as entradas permitidas para o perfil do certificado pelo nome. Por exemplo, |
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, |
output.list |
Lista os formatos de saída possíveis para o perfil do certificado pelo nome. Por exemplo, |
output.output_id.class_id |
Especifica o nome da classe java para o formato de saída nomeado no output.list. Por exemplo, |
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.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.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:
Renovar um certificado solicitando um novo certificado utilizando o pedido original de assinatura de certificado (CSR) ou um novo CSR gerado a partir da chave privada. Você pode solicitar um novo certificado usando as seguintes utilidades:
- certmonger
-
Você pode usar
certmonger
para solicitar um certificado de serviço. Antes que o certificado expire,certmonger
renovará automaticamente o certificado, garantindo assim uma validade contínua do certificado de serviço. Para obter detalhes, consulte Obtenção de um certificado IdM para um serviço usando o certmonger; - certutil
-
Você pode usar
certutil
para renovar os certificados de usuário, host e serviço. Para detalhes sobre como solicitar um certificado de usuário, consulte Solicitação de um novo certificado de usuário e sua exportação para o cliente; - openssl
-
Você pode usar
openssl
para renovar os certificados de usuário, host e serviço.
Revogar um certificado. Para detalhes, veja:
Restaurar um certificado se este tiver sido revogado temporariamente. Para maiores detalhes, veja:
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
-
No menu
Authentication
, clique emCertificates
>Certificates
. 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
-
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
ID | Motivo | Explicaçã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
-
Clique
Authentication
>Certificates
>Certificates
. 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
- Na página de informações sobre certificados, clique em Ações → Certificado de Revogação.
- 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
Use o comando
ipa cert-revoke
, e especifique:- o número de série do certificado
- o número de identificação para o motivo da revogação; veja Seção 42.2.1, “Motivos de revogação de certificados” para detalhes
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
-
No menu
Authentication
, clique emCertificates
>Certificates
. 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
- Na página de informações sobre certificados, clique em Ações → Certificado 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:
- 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.
Um administrador tem que criar uma regra de mapeamento de certificados para permitir o login bem sucedido no IdM para um usuário
- cuja conta contém um certificado de mapeamento de entrada de dados
- 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:
- Se o certificado é emitido pelo AD mas o usuário e o certificado são armazenados no IdM, o mapeamento e todo o processamento do pedido de autenticação ocorre no lado do IdM. Para detalhes de configuração deste cenário, veja Configurando o mapeamento de certificados para usuários armazenados no IdM
Se o usuário for armazenado no AD, o processamento do pedido de autenticação ocorrerá no AD. Existem três subcasos diferentes:
- A entrada do usuário AD contém o certificado completo. Para detalhes de como configurar o IdM neste cenário, veja Configurando o mapeamento de certificados para usuários cuja entrada do usuário AD contém o certificado completo.
-
O AD é configurado para mapear certificados de usuário para contas de usuário. Neste caso, a entrada do usuário do AD não contém o certificado completo, mas contém um atributo chamado
altSecurityIdentities
. Para detalhes de como configurar o IdM neste cenário, veja Configurando o mapeamento de certificados se o AD estiver configurado para mapear certificados de usuários para contas de usuários. -
A entrada do usuário AD não contém nem o certificado completo nem os dados de mapeamento. Neste caso, a única solução é usar o comando
ipa idoverrideuser-add
para adicionar o certificado inteiro à substituição do ID do usuário do AD no IdM. Para detalhes, veja Configurando o mapeamento do certificado se a entrada do usuário do AD não contiver certificado ou dados de mapeamento.
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 doclientAuth 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
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 valorRFC2253
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
-
a opção
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ínioad.example.com
e o assunto no certificado deve corresponder à entradacertmapdata
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
- Entrar na IDM web UI como administrador.
-
Navegue para
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Clique em
Add
.Figura 43.1. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM
- Digite o nome da regra.
Insira a regra de mapeamento. Por exemplo, para fazer a pesquisa IdM para as entradas
Issuer
eSubject
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})
Insira a regra de correspondência. Por exemplo, permitir somente certificados emitidos pelo
Smart Card CA
da organizaçãoEXAMPLE.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
-
Clique em
Add
na parte inferior da caixa de diálogo para adicionar a regra e fechar a caixa. 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
Obter as credenciais do administrador:
# kinit admin
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
eSubject
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 pelaSmart Card CA
da organizaçãoEXAMPLE.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: TRUEO 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
- Entre na IDM web UI como administrador.
-
Navegue para
Users
→Active users
→idm_user
. -
Encontre a opção
Certificate mapping data
e clique emAdd
. Se você tiver o certificado de
idm_user
à sua disposição: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...]
- Copie o certificado.
Na interface web da IdM, clique em
Add
ao lado deCertificate
e cole o certificado na janela que se abre.Figura 43.3. Adicionando dados de mapeamento de certificados do usuário: certificado
Alternativamente, se você não tem o certificado de
idm_user
à sua disposição, mas conhece oIssuer
e oSubject
do certificado, verifique o botão de rádio deIssuer 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
-
Clique em
Add
. Opcionalmente, se você tiver acesso a todo o certificado no formato
.pem
, verifique se o usuário e o certificado estão vinculados:Use o utilitário
sss_cache
para invalidar o registro deidm_user
no cache do SSSD e forçar uma recarga das informações deidm_user
:# sss_cache -u idm_user
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 comoidm_user
.
43.2.2.2. Adicionando dados de mapeamento de certificados a uma entrada de usuário no IdM CLI
Obter as credenciais do administrador:
# kinit admin
Se você tiver o certificado de
idm_user
à sua disposição, adicione o certificado à conta de usuário usando o comandoipa 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 oIssuer
e oSubject
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
Opcionalmente, se você tiver acesso a todo o certificado no formato
.pem
, verifique se o usuário e o certificado estão vinculados:Use o utilitário
sss_cache
para invalidar o registro deidm_user
no cache do SSSD e forçar uma recarga das informações deidm_user
:# sss_cache -u idm_user
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 comoidm_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
- Entre na IDM web UI como administrador.
-
Navegue para
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Clique em
Add
.Figura 43.5. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM
- Digite o nome da regra.
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})
Insira a regra de correspondência. Por exemplo, para permitir somente a autenticação de certificados emitidos pelo
AD-ROOT-CA
do domínioAD.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
-
Clique em
Add
. 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
Obter as credenciais do administrador:
# kinit admin
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ínioAD.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: TRUEO 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 IdMcertmapdata
. - 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
- Entre na IDM web UI como administrador.
-
Navegue para
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Clique em
Add
.Figura 43.7. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM
- Digite o nome da regra.
Insira a regra de mapeamento. Por exemplo, para fazer a pesquisa AD DC para as entradas
Issuer
eSubject
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})
Insira a regra de correspondência. Por exemplo, permitir somente certificados emitidos pelo
AD-ROOT-CA
do domínioAD.EXAMPLE.COM
para autenticar usuários ao IdM:<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
Entre no domínio:
ad.example.com
Figura 43.8. Regra de mapeamento de certificados se o AD estiver configurado para mapeamento
-
Clique em
Add
. 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
Obter as credenciais do administrador:
# kinit admin
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
eSubject
em qualquer certificado apresentado, e permitir somente os certificados emitidos peloAD-ROOT-CA
do domínioAD.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
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 dead_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 porAD-ROOT-CA
do domínioad.example.com
. -
O assunto é
<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user
:
-
O certificado que
$ 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
-
O atributo
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 IdMcertmapdata
. -
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
- Entre na IDM web UI como administrador.
-
Navegue para
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Clique em
Add
.Figura 43.9. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM
- Digite o nome da regra.
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})
Insira a regra de correspondência. Por exemplo, para permitir somente a autenticação de certificados emitidos pelo
AD-ROOT-CA
do domínioAD.EXAMPLE.COM
:<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
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
-
Clique em
Add
. 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
Obter as credenciais do administrador:
# kinit admin
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ínioAD.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: TRUEO 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
-
Navegue para
Identity
→ID Views
→Default Trust View
. Clique em
Add
.Figura 43.11. Adicionando uma nova substituição de ID de usuário na interface web do IdM
-
No campo
User to override
, digitead_user@ad.example.com
. Copie e cole o certificado de
ad_user
no campoCertificate
.Figura 43.12. Configurando a substituição do ID de usuário para um usuário AD
-
Clique em
Add
. Opcionalmente, verificar se o usuário e o certificado estão ligados:
Use o utilitário
sss_cache
para invalidar o registro dead_user@ad.example.com
no cache do SSSD e forçar uma recarga das informações dead_user@ad.example.com
:# sss_cache -u ad_user@ad.example.com
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 comoad_user@ad.example.com
.
43.5.2.2. Adicionar um certificado à substituição da ID de um usuário AD no CLI do IdM
Obter as credenciais do administrador:
# kinit admin
Adicione o certificado de
ad_user@ad.example.com
à conta do usuário usando o comandoipa 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
Opcionalmente, verificar se o usuário e o certificado estão ligados:
Use o utilitário
sss_cache
para invalidar o registro dead_user@ad.example.com
no cache do SSSD e forçar uma recarga das informações dead_user@ad.example.com
:# sss_cache -u ad_user@ad.example.com
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 comoad_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:
-
ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}
é um filtro que liga o assunto e o emissor de um certificado de cartão inteligente ao valor do atributoipacertmapdata
em uma conta de usuário do IdM, como descrito em Adicionando uma regra de mapeamento de certificados no IdM -
altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}
é um filtro que liga o assunto e o emissor de um certificado de cartão inteligente ao valor do atributoaltSecurityIdentities
em uma conta de usuário AD, como descrito em Adicionar uma regra de mapeamento de certificados se o domínio AD confiável estiver configurado para mapear certificados de usuário -
A adição da opção
--domain=ad.example.com
significa que os usuários mapeados para um determinado certificado não são pesquisados apenas no domínio localidm.example.com
, mas também no domínioad.example.com
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:
-
userCertificate;binary={cert!bin}
é um filtro que retorna entradas de usuário que incluem o certificado completo. Para usuários AD, a criação deste tipo de filtro é descrita em detalhes em Adicionando uma regra de mapeamento de certificado se a entrada do usuário AD não contém certificado ou dados de mapeamento. -
ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}
é um filtro que liga o assunto e o emissor de um certificado de cartão inteligente ao valor do atributoipacertmapdata
em uma conta de usuário do IdM, como descrito em Adicionando uma regra de mapeamento de certificados no IdM. -
altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}
é um filtro que liga o assunto e o emissor de um certificado de cartão inteligente ao valor do atributoaltSecurityIdentities
em uma conta de usuário AD, conforme descrito em Adicionar uma regra de mapeamento de certificados se o domínio AD confiável estiver configurado para mapear certificados de usuário.
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,
- você pode pular Seção 44.2, “Solicitar um novo certificado de usuário e exportá-lo para o cliente” se o usuário que você deseja autenticar usando um certificado já tem um certificado;
- você pode pular Seção 44.3, “Assegurar que o certificado e o usuário estejam ligados entre si” se o certificado do usuário tiver sido emitido pela IdM CA.
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:
Em um servidor de Gerenciamento de Identidade, obtenha privilégios de administrador e crie um script de shell para configurar o servidor.
Execute o comando
ipa-advise config-server-for-smart-card-auth
e salve sua saída em um arquivo, por exemploserver_certificate_script.sh
:# kinit admin # ipa-advise config-server-for-smart-card-auth >
server_certificate_script.sh
Adicione permissões de execução ao arquivo usando o utilitário
chmod
:# chmod x
server_certificate_script.sh
Em todos os servidores no domínio da Gestão de Identidade, execute o script
server_certificate_script.sh
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
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
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.
Você pode pular esta seção se o usuário que você deseja autenticar usando um certificado já tem um certificado.
Procedimento
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: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 bit4096
para o usuárioidm_user
no reinoIDM.EXAMPLE.COM
, definindo o apelido das chaves privadas do certificado paraidm_user
para facilitar a busca, e definindo o assunto paraCN=idm_user,O=IDM.EXAMPLE.COM
:# certutil -R -d
~/certdb/
-a -g4096
-nidm_user
-s "CN=idm_user
,O=IDM.EXAMPLE.COM" >certificate_request.csr
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:
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 oidm_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
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 apelidoidm_user
que é armazenado no arquivo~/idm_user.pem
no banco de dados~/certdb/
:# certutil -A -d
~/certdb/
-nidm_user
-t "P,,\i~/idm_user.pem
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_userUse o comando
pk12util
para exportar o certificado do banco de dados NSS para o formato PKCS12. Por exemplo, para exportar o certificado com o nicknameidm_user
do banco de dados/root/certdb
NSS para o arquivo~/idm_user.p12
:# pk12util -d
~/certdb
-o~/idm_user.p12
-nidm_user
Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFULTransfira 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/
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/
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
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).
- Se o certificado for fornecido por uma Autoridade Certificadora que não faça parte de seu ambiente de Gerenciamento de Identidade, vincule o usuário e o certificado seguindo o procedimento descrito em Vinculação de Contas de Usuário a Certificados.
- Se o certificado for fornecido pela Administração de Identidade CA, o certificado já é automaticamente adicionado na entrada do usuário e não é necessário vincular o certificado à conta do usuário. Para detalhes sobre a criação de um novo certificado no IdM, veja Seção 44.2, “Solicitar um novo certificado de usuário e exportá-lo para o cliente”.
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
- Você tem à sua disposição o certificado de usuário que deseja importar para o navegador no formato PKCS#12.
Procedimento
Abra o Firefox, depois navegue para
Preferences
→Privacy & Security
.Figura 44.1. Seção de Privacidade e Segurança em Preferências
Clique em Ver Certificados.
Figura 44.2. Ver Certificados em Privacidade e Segurança
-
Na guia
Your Certificates
, clique em Importar. Localize e abra o certificado do usuário no formato PKCS12, depois clique em OK e OK. Certifique-se de que a Autoridade de Certificado de Gerenciamento de Identidade seja reconhecida pela Firefox como uma autoridade confiável:
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
Add Exception
. CliqueView
.Figura 44.4. Veja os detalhes de um certificado
Na aba
Details
, destaque os camposCertificate Authority
.Figura 44.5. Exportação do certificado CA
-
Clique em Exportar. Salve o certificado da CA, por exemplo, como o arquivo
CertificateAuthority.crt
, depois clique em Fechar, e Cancelar.
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
Clique em Ver Certificados.
Figura 44.7. Ver Certificados em Privacidade e Segurança
-
Na guia
Authorities
, clique em Importar. Localize e abra o certificado da CA que você salvou no passo anterior no arquivoCertificateAuthority.crt
. Confie no certificado para identificar os sites, depois clique em OK e OK.
- 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
-
No navegador, navegue para a interface web de gerenciamento de identidade, por exemplo,
https:
//server.idm.example.com/ipa/ui
. Clique em Login Usando Certificado.
.Login Usando Certificado na interface web de Gerenciamento de Identidade
- 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 atributoX509_username:/path/to/file.p12
para especificar onde encontrar as informações de identidade do usuário X509. Por exemplo, para obter o TGT paraidm_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
NotaO 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.
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
Obter as credenciais do administrador da IdM:
~]$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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.
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
.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
ImportanteVocê 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.
-
o comando
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
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
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
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.
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ãosubCA
, 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 successfulSe 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 successfulA saída mostra que foi criada uma RSC e está armazenada no arquivo
/var/lib/ipa/ca.csr
.
-
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. 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.
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
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
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.
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
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:
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.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
Reinicie o IdM com o parâmetro
--force
:# reinício do ipactl --force
Com o parâmetro
--force
, o utilitárioipactl
ignora falhas individuais na inicialização do serviço. Por exemplo, se o servidor também for uma CA com certificados vencidos, o serviçopki-tomcat
não inicia. Isto é esperado e ignorado devido ao uso do parâmetro--force
.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.Se o servidor também for uma CA, o comando anterior informa
CA_UNREACHABLE
para o certificado que o serviçopki-tomcat
utiliza:Request ID '20190522120835': status: CA_UNREACHABLE subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205 ...
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
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
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
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
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
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 ocommand-line interface
(CLI), que permite ao administrador do sistema enviar comandos ativamente para o daemoncertmonger
.
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
No cliente
my_company.idm.example.com
IdM no qual o serviçoHTTP
está funcionando, solicite um certificado para o serviço correspondente ao principalHTTP/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 demy_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 comandoipa-getcert request
é um atalho paragetcert 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 DNSSubjectAltName
a ser adicionado à solicitação. -
A opção
-C
instruicertmonger
a reiniciar o serviçohttpd
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
.
NotaO 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.-
O comando
-
O certificado deve ser armazenado no arquivo local
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”
- Figura 48.2, “Certmonger solicitando um certificado de serviço”
- Figura 48.3, “IdM CA emitindo o certificado de serviço”
- Figura 48.4, “Certmonger aplicando o certificado de serviço”
- Figura 48.5, “Certmonger solicitando um novo certificado quando o antigo está quase expirando”
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
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
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
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
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
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:
- No servidor da IdM, você cria um certificado para um sistema que ainda não existe.
- Você cria o novo sistema.
- Você cadastra o novo sistema como um cliente IdM.
- Você importa o certificado e a chave do servidor da IdM para o cliente da IdM.
-
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 valorIPA
ao comandogetcert start-tracking
se o certificado tiver sido emitido pela IDM CA. Omitir a adição da opção-c
resulta emcertmonger
entrando no estado NEED_CA.Para mais opções, consulte a página de manual
getcert start-tracking
.
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 manualgetcert 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
Obtenha o PIN para os certificados do subsistema CA:
# grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
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"'
Adicione rastreamento para os certificados IdM restantes, os certificados
HTTP
,LDAP
,IPA renewal agent
ePKINIT
:# 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
Reinicie
certmonger
:# systemctl restart certmonger
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 sistemacertificate
, 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
.
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.
NotaVocê 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
Optional: Criar um arquivo de inventário, por exemplo
inventory.file
:inventário.file $ touch
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
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, comowebserver
. Defina a variável
certificate_requests
para incluir o seguinte:-
Ajuste o parâmetro
name
para o nome desejado do certificado, tal comomycert
. -
Defina o parâmetro
dns
para o domínio a ser incluído no certificado, tal como*.example.com
. -
Ajustar o parâmetro
ca
paraself-sign
.
-
Ajuste o parâmetro
Definir o papel do
rhel-system-roles.certificate
emroles
.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
-
Defina
- Salvar o arquivo.
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 sistemacertificate
, 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 manualansible-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
.
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.
NotaVocê 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
Optional: Criar um arquivo de inventário, por exemplo
inventory.file
:inventário.file $ touch
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
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, comowebserver
. Defina a variável
certificate_requests
para incluir o seguinte:-
Ajuste o parâmetro
name
para o nome desejado do certificado, tal comomycert
. -
Defina o parâmetro
dns
para o domínio a ser incluído no certificado, tal comowww.example.com
. -
Definir o parâmetro
principal
para especificar o principal Kerberos, tal comoHTTP/www.example.com@EXAMPLE.COM
. -
Ajustar o parâmetro
ca
paraipa
.
-
Ajuste o parâmetro
Definir o papel do
rhel-system-roles.certificate
emroles
.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
-
Defina
- Salvar o arquivo.
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 sistemacertificate
, 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 manualansible-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.
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.
NotaVocê 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
Optional: Criar um arquivo de inventário, por exemplo
inventory.file
:inventário.file $ touch
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
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, comowebserver
. Defina a variável
certificate_requests
para incluir o seguinte:-
Ajuste o parâmetro
name
para o nome desejado do certificado, tal comomycert
. -
Defina o parâmetro
dns
para o domínio a ser incluído no certificado, tal comowww.example.com
. -
Defina o parâmetro
ca
para a CA que você deseja usar para emitir o certificado, tal comoself-sign
. -
Ajuste o parâmetro
run_before
para o comando que você deseja executar antes da emissão ou renovação deste certificado, tal comosystemctl 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 comosystemctl start httpd.service
.
-
Ajuste o parâmetro
Definir o papel do
rhel-system-roles.certificate
emroles
.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
-
Defina
- Salvar o arquivo.
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 sistemacertificate
, 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 manualansible-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:
- Criar um sub-CA IdM
- Baixe o certificado de sub-CA da IdM WebUI
- Criar uma ACL CA especificando a combinação correta de usuários, serviços e ACs, e o perfil de certificado utilizado
- Solicitar um certificado para o serviço web executado em um cliente IdM da sub-CA da IdM
- Configurar um Servidor HTTP Apache de uma única instância
- Adicionar a criptografia TLS ao Servidor HTTP Apache
- Definir as versões do protocolo TLS suportadas em um Servidor HTTP Apache
- Configure as cifras suportadas no Servidor HTTP Apache
- Configurar a autenticação do certificado do cliente TLS no servidor web
- Solicitar um certificado para o usuário da sub-CA da IdM e exportá-lo para o cliente
- Importar o certificado de usuário para o navegador e configurar o navegador para confiar no certificado de sub-CA
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
- No menu Authentication, clique em Certificates.
- Selecione Certificate Authorities e clique em Add.
- 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.
- Digite o nome da sub-CA webclient-ca. Digite o Subject DN CN=WEBCLIENT,O=IDM.EXAMPLE.COM no campo Subject DN.
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
ImportanteEsquecer 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.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,uNotaO 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
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.
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.COMNa 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
ImportanteEsquecer 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.
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
NotaO 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
No menu Authentication, clique em Certificates > Certificates.
Figura 50.1. sub-CA certificado na lista de certificados
- Clique no número de série do certificado de sub-CA para abrir a página de informações do certificado.
- Na página de informações sobre certificados, clique em Actions > Download.
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
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
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
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
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
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 -------------------------
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 -------------------------
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.
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
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
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
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 -------------------------
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 -------------------------
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.
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
No cliente
my_company.idm.example.com
IdM no qual o serviçoHTTP
está funcionando, solicite um certificado para o serviço correspondente ao principalHTTP/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 demy_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 comandoipa-getcert request
é um atalho paragetcert 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 DNSSubjectAltName
a ser adicionado à solicitação. -
A opção
-X
especifica que o emissor do certificado deve serwebserver-ca
, e nãoipa
. -
A opção
-C
instruicertmonger
a reiniciar o serviçohttpd
após a obtenção do certificado.
-
Para especificar que o certificado seja emitido com um determinado perfil, use a opção
-T
.
NotaO 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.-
O comando
-
O certificado deve ser armazenado no arquivo local
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:
- Figura 50.2, “Comunicação não criptografada”
- Figura 50.3, “Certmonger solicitando um certificado de serviço”
- Figura 50.4, “IdM CA emitindo o certificado de serviço”
- Figura 50.5, “Certmonger aplicando o certificado de serviço”
- Figura 50.6, “Certmonger solicitando um novo certificado quando o antigo está quase expirando”
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
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
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
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
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
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
Instale o pacote
httpd
:# yum instalar httpd
Abra a porta TCP
80
no firewall local:# firewall-cmd --permanent --add-port=80/tcp # firewall-cmd --reload
Habilite e inicie o serviço
httpd
:# systemctl enable --now httpd
Opcional: Adicionar arquivos HTML ao diretório
/var/www/html/
.NotaAo adicionar conteúdo a
/var/www/html/
, arquivos e diretórios devem ser legíveis pelo usuário, sob o qualhttpd
é executado por padrão. O proprietário do conteúdo pode ser o usuárioroot
e o grupo de usuáriosroot
, ou outro usuário ou grupo da escolha do administrador. Se o proprietário do conteúdo for o usuárioroot
e o grupo de usuáriosroot
, os arquivos devem ser legíveis por outros usuários. O contexto SELinux para todos os arquivos e diretórios deve serhttpd_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/
ouhttp://server_IP/
.Se o diretório
/var/www/html/
estiver vazio ou não contiver um arquivoindex.html
ouindex.htm
, o Apache exibe oRed 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 exemplohttp://server_IP/example.html
ouhttp://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 manualhttpd.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
Instale o pacote
mod_ssl
:# dnf install mod_ssl
Edite o arquivo
/etc/httpd/conf.d/ssl.conf
e adicione as seguintes configurações à diretiva<VirtualHost _default_:443>
:Defina o nome do servidor:
ServerName my_company.idm.example.com
ImportanteO nome do servidor deve corresponder à entrada definida no campo
Common Name
do certificado.Opcional: Se o certificado contiver nomes de host adicionais no campo
Subject Alt Names
(SAN), você pode configurarmod_ssl
para fornecer criptografia TLS também para esses nomes de host. Para configurar isto, adicione o parâmetroServerAliases
com os nomes correspondentes:ServerAlias www.my_company.idm.example.com server.my_company.idm.example.com
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"
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çãoSe 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.
Abra a porta
443
no firewall local:# firewall-cmd --permanent --add-port=443 # firewall-cmd --reload
Reinicie o serviço
httpd
:# systemctl restart httpd
NotaSe 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
.
-
Use um navegador e conecte-se a
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) ouTLS1.1
. -
Se você quiser configurar que o Apache suporta apenas o protocolo
TLSv1.2
ouTLSv1.3
.
Pré-requisitos
- A criptografia TLS está habilitada no servidor my_company.idm.example.com, conforme descrito em Seção 50.7, “Adicionando criptografia TLS a um Servidor HTTP Apache”.
Procedimento
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 protocoloTLSv1.3
:SSLProtocol -Todos os TLSv1.3
Reinicie o serviço
httpd
:# systemctl restart httpd
Etapas de verificação
Use o seguinte comando para verificar se o servidor suporta
TLSv1.3
:# openssl s_client -connect example.com:443 -tls1_3
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
- Opcional: Repetir o comando para outras versões do protocolo TLS.
Recursos adicionais
-
Para mais detalhes sobre a política de criptografia do sistema, consulte a página de manual
update-crypto-policies(8)
e Utilizando políticas criptográficas de todo o sistema. -
Para mais detalhes sobre o parâmetro
SSLProtocol
, consulte a documentaçãomod_ssl
no manual do Apache. Para detalhes sobre a instalação do manual, consulte o manual Instalando o Servidor HTTP Apache.
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
- A criptografia TLS está habilitada no servidor my_company.idm.example.com, conforme descrito em Seção 50.7, “Adicionando criptografia TLS a um Servidor HTTP Apache”.
Procedimento
Edite o arquivo
/etc/httpd/conf/httpd.conf
, e adicione o parâmetroSSLCipherSuite
à 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
eAES256 EDH
e desativa todas as cifras que utilizam o código de autenticação de mensagens (MAC)SHA1
eSHA256
.Reinicie o serviço
httpd
:# systemctl restart httpd
Etapas de verificação
Para exibir a lista de cifras que o Servidor HTTP Apache suporta:
Instale o pacote
nmap
:nmap # yum instalar nmap
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
-
Para mais detalhes sobre a política de criptografia do sistema, consulte a página de manual
update-crypto-policies(8)
e Utilizando políticas criptográficas de todo o sistema. -
Para mais detalhes sobre o parâmetro
SSLCipherSuite
, consulte a documentaçãomod_ssl
no manual do Apache. Para detalhes sobre a instalação do manual, consulte o manual Instalando o Servidor HTTP Apache.
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/
.
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
- A criptografia TLS está habilitada no servidor my_company.idm.example.com, conforme descrito em Seção 50.7, “Adicionando criptografia TLS a um Servidor HTTP Apache”.
Procedimento
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/
.Reinicie o serviço
httpd
:# systemctl restart httpd
Etapas de verificação
Use o utilitário
curl
para acessar a URLhttps://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.
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 arquivoindex.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
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: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 bit4096
para o usuárioidm_user
no reinoIDM.EXAMPLE.COM
, definindo o apelido das chaves privadas do certificado paraidm_user
para facilitar a busca, e definindo o assunto paraCN=idm_user,O=IDM.EXAMPLE.COM
:# certutil -R -d
~/certdb/
-a -g4096
-nidm_user
-s "CN=idm_user
,O=IDM.EXAMPLE.COM" >certificate_request.csr
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:
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 oidm_user
@IDM.EXAMPLE.COM
principal dewebclient-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
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 apelidoidm_user
que é armazenado no arquivo~/idm_user.pem
no banco de dados~/certdb/
:# certutil -A -d
~/certdb/
-nidm_user
-t "P,,\i~/idm_user.pem
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_userUse o comando
pk12util
para exportar o certificado do banco de dados NSS para o formato PKCS12. Por exemplo, para exportar o certificado com o nicknameidm_user
do banco de dados/root/certdb
NSS para o arquivo~/idm_user.p12
:# pk12util -d
~/certdb
-o~/idm_user.p12
-nidm_user
Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFULTransfira 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/
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/
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
- Você tem à sua disposição o certificado de usuário que deseja importar para o navegador no formato PKCS#12.
- Você baixou o certificado de sub-CA e o tem à sua disposição no formato PEM.
Procedimento
Abra o Firefox, depois navegue para
Preferences
→Privacy & Security
.Figura 50.7. Seção de Privacidade e Segurança em Preferências
Clique em Ver Certificados.
Figura 50.8. Ver Certificados em Privacidade e Segurança
-
Na guia
Your Certificates
, clique em Importar. Localize e abra o certificado do usuário no formato PKCS12, depois clique em OK e OK. 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:
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
Clique em Ver Certificados.
Figura 50.10. Ver Certificados em Privacidade e Segurança
-
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 51. Invalidação rápida de um grupo específico de certificados relacionados
Como administrador do sistema, se você quiser ser capaz de invalidar rapidamente um grupo específico de certificados relacionados:
- Projete suas aplicações para que elas só confiem em certificados emitidos por uma sub-CA específica de Gerenciamento de Identidade (IdM) leve. Depois disso, você poderá invalidar todos estes certificados, revogando apenas o certificado da sub-CA de Gerenciamento de Identidade (IdM) que emitiu estes certificados. Para detalhes sobre como criar e usar uma sub-CA leve em IdM, veja Capítulo 50, Restringindo um pedido de confiança apenas a um subconjunto de certificados.
Para garantir que todos os certificados que foram emitidos pelo sub-CA IdM a ser invocado sejam imediatamente inválidos, configure as aplicações que dependem de tais certificados para usar os respondedores do IdM OCSP. Por exemplo, para configurar o navegador Firefox para usar os respondedores OCSP, certifique-se de que a caixa de seleção
Query OCSP responder servers to confirm the current validity of certificates
esteja marcada em Preferências do Firefox.Na IdM, a lista de revogação de certificados (CRL) é atualizada a cada quatro horas.
Para invalidar todos os certificados emitidos por uma sub-CA IdM, revogar o certificado da sub-CA IdM. Além disso, desabilitar as ACLs CA relevantes e considerar a desabilitação da sub-CA IdM. A desativação da sub-CA impede que a sub-CA emita novos certificados, mas permite que respostas do Protocolo de Status de Certificado On-line (OCSP) sejam produzidas para certificados emitidos anteriormente, porque as chaves de assinatura da sub-CA são retidas.
Não exclua o sub-CA se você usar OCSP em seu ambiente. A exclusão do sub-CA elimina as chaves de assinatura do sub-CA, impedindo a produção de respostas OCSP para certificados emitidos por esse sub-CA.
O único cenário ao excluir uma sub-CA é preferível a desativá-la quando se deseja criar uma nova sub-CA com o mesmo nome distinto de Assunto (DN), mas com uma nova chave de assinatura.
51.1. Desabilitando ACLs CA em IdM CLI
Quando você quiser aposentar um serviço IdM ou um grupo de serviços IdM, considere a possibilidade de desativar quaisquer ACLs CA correspondentes existentes.
Complete esta seção para desativar o TLS_web_server_authentication CA ACL que restringe o servidor web executado em seu cliente IdM para solicitar um certificado a ser emitido pela sub-CA webserver-ca
IdM, e para desativar o TLS_web_client_authentication CA ACL que restringe os usuários IdM para solicitar um certificado de usuário a ser emitido pela sub-CA webclient-ca
IdM.
Procedimento
Opcionalmente, para visualizar todas as ACLs CA em seu ambiente IdM, digite o comando
ipa caacl-find
:$ ipa caacl-find ----------------- 3 CA ACLs matched ----------------- ACL name: hosts_services_caIPAserviceCert Enabled: TRUE ACL name: TLS_web_server_authentication Enabled: TRUE ACL name: TLS_web_client_authentication Enabled: TRUE
Opcionalmente, para visualizar os detalhes de uma CA ACL, digite o comando
ipa caacl-show
e especifique o nome da CA ACL:$ ipa caacl-show 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 CAs: webserver-ca Profiles: caIPAserviceCert Services: HTTP/rhel8server.idm.example.com@IDM.EXAMPLE.COM
Para desativar uma CA ACL, digite o comando
ipa caacl-disable
, e especifique o nome da CA ACL.Para desativar a CA ACL TLS_web_server_authentication, entre:
$ ipa caacl-disable TLS_web_server_authentication ------------------------------------------------- Disabled CA ACL "TLS_web_server_authentication" -------------------------------------------------
Para desativar a CA ACL TLS_web_client_authentication, entre:
$ ipa caacl-disable TLS_web_client_authentication ------------------------------------------------- Disabled CA ACL "TLS_web_client_authentication" -------------------------------------------------
A única CA ACL habilitada agora é a hosts_services_caIPAserviceCert CA ACL.
ImportanteSeja extremamente cuidadoso ao desativar a CA ACL
hosts_services_caIPAserviceCert
. Desativarhosts_services_caIPAserviceCert
, sem que outra CA ACL conceda aos servidores da IdM o uso daipa
CA com o perfilcaIPAserviceCert
significa que a renovação do certificado da IdMHTTP
eLDAP
falhará. Os certificados expirados do IdMHTTP
eLDAP
eventualmente causarão falha no sistema IdM.
51.2. Desabilitando um sub-CA IdM
Após revogar o certificado CA de uma sub-CA IdM a fim de invalidar todos os certificados emitidos por essa sub-CA, considere desativar a sub-CA IdM se você não precisar mais dela. Você pode reativar a sub-CA em um momento posterior.
A desativação do sub-CA impede que o sub-CA emita novos certificados, mas permite que sejam produzidas respostas do Protocolo de Status de Certificado Online (OCSP) para certificados emitidos anteriormente, porque as chaves de assinatura do sub-CA são retidas.
Pré-requisitos
- Você está logado como administrador da IdM.
Procedimento
Digite o comando
ipa ca-disable
e especifique o nome do sub-CA:$ ipa ca-disable webserver-CA -------------------- Disabled CA "webserver-CA" --------------------
Capítulo 52. Cofre em IdM
Este capítulo descreve os cofres em Gerenciamento de Identidade (IdM). Ele introduz os seguintes tópicos:
- O conceito do cofre.
- Os diferentes papéis associados a um cofre.
- Os diferentes tipos de cofres disponíveis na IdM com base no nível de segurança e controle de acesso.
- Os diferentes tipos de cofres disponíveis na IdM com base na propriedade.
- O conceito de recipientes abobadados.
- Os comandos básicos para o gerenciamento de cofres na IdM.
- Instalação da autoridade chave de recuperação (KRA), que é um pré-requisito para o uso de cofres na IdM.
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.
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.
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.
NotaOs 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 comoipa 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
- Certos privilégios de proprietário e membro dependem do tipo do cofre. Consulte Cofre padrão, simétrico e assimétrico para maiores detalhes.
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
Tipo | Descrição | Proprietário | Nota |
---|---|---|---|
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
Tipo | Descrição | Objetivo |
---|---|---|
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.
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
Comando | Objetivo |
---|---|
| Exibe informações conceituais sobre cofres do IdM e exemplos de comandos de cofres. |
|
Adicionar a opção |
| 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 |
| 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
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
- O componente do Sistema de Certificado da Key Recovery Authority (KRA) foi instalado em um ou mais servidores em seu domínio IdM. Para detalhes, consulte Instalando a Autoridade de Recuperação de Chaves no IdM.
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
Obter o bilhete de concessão do bilhete Kerberos (TGT) para
idm_user
:$ kinit idm_user
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
ImportanteCertifique-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 parauser1
, o proprietário do cofre do usuário também seráadmin
, euser1
não poderá acessar o cofre do usuário ou criar novos cofres de usuário.Use o comando
ipa vault-archive
com a opção--in
para arquivar o arquivosecret.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
SSH para idm_client como idm_user:
$ ssh idm_user@idm_client.idm.example.com
Faça o login como
idm_user
:$ kinit user
Use o comando
ipa vault-retrieve --out
com a opção--out
para recuperar o conteúdo do cofre e salvá-lo no arquivosecret_exported.txt
.$ ipa vault-retrieve my_vault --out secret_exported.txt -------------------------------------- Retrieved data from vault "my_vault" --------------------------------------
Recursos adicionais
- Você pode usar o Ansible para automatizar o processo de gerenciamento dos cofres do usuário IdM. Para mais informações, consulte Utilizando Ansible para gerenciar os cofres do usuário IdM: armazenando e recuperando segredos.
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
- O componente do Sistema de Certificado da Key Recovery Authority (KRA) foi instalado em um ou mais servidores em seu domínio IdM. Para detalhes, consulte Instalando a Autoridade de Recuperação de Chaves no IdM.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Criar um arquivo de inventário, por exemplo inventory.file:
$ touch inventory.file
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
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
- Abra o arquivo ensure-standard-vault-is-present-copy.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
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
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
- Abra o arquivo data-archive-in-standard-vault-copy.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
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
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
- Abra o arquivo retrieve-data-standard-vault.yml-copy.yml para edição.
-
Adapte o arquivo, definindo a variável
hosts
para ipahost. 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
-
Defina a variável
- Salvar o arquivo.
Execute o livro de brincadeiras:
$ ansible-playbook -v -i inventory.file retrieve-data-standard-vault.yml-copy.yml
Etapas de verificação
SSH
a host01 como user01:$ ssh user01@host01.idm.example.com
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:
-
Gerar uma chave privada usando, por exemplo, o utilitário
openssl
. - 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
- O componente do Sistema de Certificado da Key Recovery Authority (KRA) foi instalado em um ou mais servidores em seu domínio IdM. Para detalhes, consulte Instalando a Autoridade de Recuperação de Chaves no IdM.
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
Faça o login como administrador:
$ kinit admin
Obter a chave pública da instância de serviço. Por exemplo, utilizando a utilidade
openssl
: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)
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
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.
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
- Você tem acesso ao keytab do diretor do serviço proprietário do cofre de serviço, por exemplo HTTP/webserver.idm.example.com.
- Você criou uma abóbada assimétrica e arquivou um segredo na abóbada.
- Você tem acesso à chave privada utilizada para recuperar o segredo do cofre de serviço.
Procedimento
Faça o login como administrador:
$ kinit admin
Obter um bilhete Kerberos para o serviço:
# kinit HTTP/webserver.idm.example.com -k -t /etc/httpd/conf/ipa.keytab
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
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.
- 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
- Você pode usar o Ansible para automatizar o processo de gerenciamento dos cofres de serviço IdM. Para mais informações, consulte Utilizando Ansible para gerenciar os cofres de serviço IdM: armazenando e recuperando segredos.
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:
-
Gerar uma chave privada usando, por exemplo, o utilitário
openssl
. - 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
- O componente do Sistema de Certificado da Key Recovery Authority (KRA) foi instalado em um ou mais servidores em seu domínio IdM. Para detalhes, consulte Instalando a Autoridade de Recuperação de Chaves no IdM.
Esta seção inclui estes procedimentos:
- Garantir a presença de um cofre de serviço assimétrico na IdM usando o Ansible
- Armazenando um segredo de serviço IdM em um cofre assimétrico usando o Ansible
- Recuperar um segredo de serviço para um serviço IdM usando o Ansible
- Mudando um segredo do cofre de serviço IdM quando comprometido usando o Ansible
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Obter a chave pública da instância de serviço. Por exemplo, utilizando a utilidade
openssl
: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)
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
Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:
$ touch inventory.file
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
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
- Abra o arquivo ensure-asymmetric-vault-is-present-copy.yml para edição.
- Adicione uma tarefa que copia a chave pública service-public.pem do controlador Ansible para o servidor server.idm.example.com.
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
-
Defina a variável
- Salvar o arquivo.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:
$ touch inventory.file
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
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
- Abra o arquivo data-archive-in-asymmetric-vault-copy.yml para edição.
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
paramember
.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
-
Defina a variável
- Salvar o arquivo.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:
$ touch inventory.file
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
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
- Abra o arquivo data-archive-in-asymmetric-vault-copy.yml para edição.
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
paramember
.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
-
Defina a variável
- Salvar o arquivo.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:
$ touch inventory.file
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
-
Defina seu servidor IdM na seção
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
- Abra o arquivo retrieve-data-asymmetric-vault-copy.yml para edição.
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
paramember
.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
-
Defina a variável
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
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
- Salvar o arquivo.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
-
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: 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
ImportanteCertifique-se de que a lista não contém o servidor web comprometido, no exemplo atual webserver3.idm.example.com.
-
O servidor da IdM na seção
- Abra o arquivo data-archive-in-asymmetric-vault-copy.yml para edição.
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
paramember
.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
-
Defina a variável
- Salvar o arquivo.
Execute o livro de brincadeiras:
$ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml
- Abra o arquivo retrieve-data-asymmetric-vault-copy.yml para edição.
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
paramember
.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
-
Defina a variável
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
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
- Salvar o arquivo.
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:
Verifique se um serviço instalado manualmente está presente em um cliente IdM e instale automaticamente esse serviço se ele estiver ausente. Para detalhes, veja:
Verifique se um serviço inscrito na IdM tem um certificado anexado e instale automaticamente esse certificado se ele estiver ausente. Para maiores detalhes, veja:
Permitir que usuários e anfitriões da IdM recuperem e criem a tabela de chave de serviço. Para detalhes, veja:
Permitir que os usuários e anfitriões da IdM adicionem um pseudônimo Kerberos a um serviço. Para detalhes, veja:
Verifique se um serviço não está presente em um cliente IdM e remova automaticamente esse serviço se ele estiver presente. Para maiores detalhes, veja:
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
Criar um arquivo de inventário, por exemplo
inventory.file
:$ touch inventory.file
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
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
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
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 tarefaipaservice
.
-
Alterar a senha do administrador da IdM definida pela variável
- Salvar e sair do arquivo.
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
- Entre na IDM Web UI como administrador da IdM.
-
Navegue para
Identity
→Services
.
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
- Você pode assegurar a comunicação entre o servidor HTTP e os clientes do navegador adicionando a criptografia TLS a um Servidor HTTP Apache.
- Você pode solicitar um certificado para o serviço HTTP a uma autoridade certificadora da IdM. Para mais informações, consulte o procedimento descrito em Obtenção de um certificado IdM para um serviço usando o certmonger.
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
- Você instalou um serviço HTTP em seu host.
- O host no qual você configurou o HTTP não é um cliente IdM. Caso contrário, siga os passos para Garantir a presença de um serviço HTTP no IdM usando um livro de exercícios possível.
- Você tem a senha de administrador da IdM.
- O registro DNS A - ou o registro AAAA, se for usado IPv6 - para o host está disponível.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
:$ touch inventory.file
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
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
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áveisipaadmin_password
ename
na tarefaipaservice
:--- - 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
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.
-
Defina a variável
- Salvar e sair do arquivo.
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
- Entre na IDM Web UI como administrador da IdM.
-
Navegue para
Identity
→Services
.
Agora você pode ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM listado na lista Services.
Recursos adicionais
- Você pode assegurar a comunicação entre o servidor HTTP e os clientes do navegador adicionando a criptografia TLS a um Servidor HTTP Apache.
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
- O sistema para hospedar o serviço HTTP está registrado na IdM.
- O registro DNS A ou DNS AAAA para o anfitrião pode não existir. Caso contrário, se o registro DNS para o host existir, siga o procedimento em Garantir a presença de um serviço HTTP no IdM usando um playbook Ansible.
- Você tem a senha de administrador da IdM.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
:$ touch inventory.file
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
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
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áveisipaadmin_password
ename
na tarefaipaservice
:--- - 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
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.
-
Defina a variável
- Salvar e sair do arquivo.
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
- Entre na IDM Web UI como administrador da IdM.
-
Navegue para
Identity
→Services
.
Agora você pode ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM listado na lista Services.
Recursos adicionais
- Você pode assegurar a comunicação entre o servidor HTTP Apache e os clientes do navegador adicionando a criptografia TLS ao Servidor HTTP Apache.
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
- Você instalou um serviço HTTP em seu host.
- Você cadastrou o serviço HTTP para a IdM.
- Você tem a senha de administrador da IdM.
- Você tem um certificado assinado externamente, cujo Assunto corresponde ao principal do serviço HTTP.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
:$ touch inventory.file
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
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
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
Decodifique o arquivo
DER
para a saída padrão usando o comandobase64
. Use a opção-w0
para desativar a embalagem:$ base64 cert1.der -w0 MIIC/zCCAeegAwIBAgIUV74O+4kXeg21o4vxfRRtyJm...
- Copie o certificado da saída padrão para a prancheta.
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
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ávelcertificate:
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.
-
Substitua o certificado, definido usando a variável
- Salvar e sair do arquivo.
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
- Entre na IDM Web UI como administrador da IdM.
-
Navegue para
Identity
→Services
. - 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
Criar um arquivo de inventário, por exemplo
inventory.file
:$ touch inventory.file
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
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
-
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. 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çãotasks
.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
-
A senha do administrador da IdM especificada pela variável
- Salvar o arquivo.
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
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:
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
Criar um arquivo de inventário, por exemplo
inventory.file
:$ toque inventory.file
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
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
-
Abra o arquivo copiado,
/usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml
, para edição: Adaptar o arquivo:
-
Defina a variável
ipaadmin_password
para sua senha de administrador IdM. -
Defina a variável
name
da tarefaipaservice
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çãotasks
.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
-
Defina a variável
- Salvar o arquivo.
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
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:
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
- Você sabe a senha do administrador da IdM.
- Você instalou o pacote ansible-freeipa no controlador Ansible.
- Você instalou um serviço HTTP em seu host.
- Você cadastrou o serviço HTTP para a IdM.
- O host no qual você configurou o HTTP é um cliente IdM.
Procedimento
Criar um arquivo de inventário, por exemplo
inventory.file
:$ touch inventory.file
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
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
-
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. 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ávelname
. No exemplo atual, é host/mycompany.idm.example.com. O nome da tarefa especificada pela variável
name
na seçãotasks
.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
-
A senha do administrador da IdM especificada pela variável
- Salvar o arquivo.
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
- Para mais informações sobre os pseudônimos principais do Kerberos e sua administração sem Ansible, veja Managing Kerberos principal aliases for users, hosts, and services.
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
Criar um arquivo de inventário, por exemplo
inventory.file
:$ touch inventory.file
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
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
-
Abrir o arquivo
/usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml
Um possível arquivo de playbook para edição. 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 tarefaipaservice
.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
-
A senha de administrador da IdM definida pela variável
- Salvar e sair do arquivo.
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
- Entre na IDM Web UI como administrador da IdM.
-
Navegue para
Identity
→Services
.
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.
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.
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
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 grupoadmins
:# 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.
Destruir o atual bilhete Kerberos do administrador da IdM:
# kdestroy -A
NotaA 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.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:
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.
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
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 ----------------------------
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
Autenticar-se na IdM como usuário do
admin
:$ parentes admin
Acrescente o pseudônimo ao principal anfitrião. Por exemplo, para adicionar o pseudônimo
demo
ao principal anfitriãodemo.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
Defina o parâmetro
dns_canonicalize_hostname
na seção[libdefaults]
no arquivo/etc/krb5.conf
parafalse
:[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
O serviço DNS é instalado no servidor da IdM. Para mais informações sobre como instalar um servidor IdM com DNS integrado, veja um dos links a seguir:
Este capítulo inclui as seguintes seções:
- Como a IdM garante que os forwarders globais do /etc/resolv.conf não sejam removidos pelo NetworkManager
- Garantindo a presença de um forwarder global DNS na IdM usando o Ansible
- Garantindo a ausência de um encaminhador global DNS na IdM usando o Ansible
- Uma introdução às políticas de encaminhamento de DNS na IdM
- 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
- Utilização de um caderno de exercícios possível para garantir que os encaminhadores globais sejam desativados no DNS da IdM
- Utilização de um livro de reprodução possível para garantir que a sincronização de zonas de pesquisa para frente e para trás seja desativada no DNS do IdM
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:
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
-
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 arquivozzz-ipa.conf
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
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
-
Abra o arquivo
ensure-presence-of-a-global-forwarder.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure the presence of a global forwarder in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
. Na seção
forwarders
da parteipadnsconfig
:-
Alterar o primeiro valor
ip_address
para o endereço IPv4 do forwarder global:7.7.9.9
. -
Altere o segundo valor
ip_address
para o endereço IPv6 do forwarder global:2001:db8::1:0
. -
Verifique se o valor
port
está definido para53
.
-
Alterar o primeiro valor
Mude o
state
parapresent
.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
-
Altere a variável
- Salvar o arquivo.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
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
-
Abra o arquivo
ensure-absence-of-a-global-forwarder.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure the absence of a global forwarder in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
. Na seção
forwarders
da parteipadnsconfig
:-
Alterar o primeiro valor
ip_address
para o endereço IPv4 do forwarder global:8.8.6.6
. -
Altere o segundo valor
ip_address
para o endereço IPv6 do forwarder global:2001:4860:4860::8800
. -
Verifique se o valor
port
está definido para53
.
-
Alterar o primeiro valor
Verifique se o site
state
está configurado paraabsent
.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
-
Altere a variável
- Salvar o arquivo.
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.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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
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
- Abra o arquivo set-forward-policy-to-first.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnsconfig.md
Markdown disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsconfig
. -
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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
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
- Abra o arquivo disable-global-forwarders-copy.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnsconfig.md
Markdown disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsconfig
. -
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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
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
- Abra o arquivo disallow-reverse-sync-copy.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnsconfig.md
Markdown disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsconfig
. -
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
O serviço DNS é instalado no servidor da IdM. Para mais informações sobre como instalar um servidor IdM com DNS integrado, veja um dos links a seguir:
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.
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 comandosipa dnszone-*
.Em conformidade com as regras DNS padrão, cada zona primária deve conter registros
start of authority
(SOA) enameserver
(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 nomesub.test.example.
. Além disso, a zonatest.example.
é configurada com o endereço IP do reencaminhador192.0.2.254
para a subzonasub.text.example
.Um cliente que pergunta o nome
nonexistent.test.example.
recebe a respostaNXDomain
, 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 configurado192.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
Na interface web da IdM, clique em
Network Services
→DNS
→DNS Zones
.Figura 62.1. Gerenciando zonas primárias DNS IdM
- Clique em Adicionar no topo da lista de todas as zonas.
Forneça o nome da zona.
Figura 62.2. Entrando em uma nova zona primária IdM
- 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 comandoipa 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
-
Na interface web da IdM, clique em
Network Services
→DNS
→DNS Zones
. Selecione a caixa de seleção pelo nome da zona e clique em Excluir.
Figura 62.3. Remoção de uma zona DNS principal
- 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-*
eipa 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:
-
O comando
dnszone-mod
na interface de linha de comando (CLI). Para mais informações, consulte Editando a configuração de uma zona DNS primária no IdM CLI. - A IDM Web UI. Para mais informações, consulte Editando a configuração de uma zona DNS primária na Interface Web IdM.
-
Um caderno de exercícios possível que utiliza o módulo
ipadnszone
. Para mais informações, consulte Utilização de playbooks ansíveis para gerenciar zonas DNS IdM.
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
Atributo | Opção de Linha de Comando | Descrição |
---|---|---|
Servidor de nomes autorizado |
| 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 |
Endereço de e-mail do administrador |
| 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 |
| 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 |
| 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 |
| Define o tempo, em segundos, para esperar antes de tentar novamente uma operação de atualização falhada. |
A SOA expira |
| 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 |
| Define o valor de tempo de vida (TTL) em segundos para cache negativo de acordo com a RFC 2308. |
Tempo de SOA para viver |
|
Define TTL em segundos para registros no ápice da zona. Na zona |
Tempo padrão para viver |
|
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 |
Política de atualização BIND |
| Define as permissões permitidas aos clientes na zona DNS. |
Atualização dinâmica |
| 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 |
| 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 |
Permitir consulta |
| 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 |
| 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 |
| 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 |
| 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
Na interface web da IdM, clique em
Network Services
→DNS
→DNS Zones
.Figura 62.4. Gestão de zonas primárias DNS
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
Clique em
Settings
.Figura 62.6. A guia Configurações na página de edição da zona primária
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.
Clique em Salvar para confirmar a nova configuração.
NotaSe 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.NotaSe 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 comandoipa 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.
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
- Para mais informações sobre como proceder para habilitar transferências de zona na IDM Web UI, consulte Habilitação de transferências de zona na IdM Web UI.
- Para mais informações sobre como proceder para permitir transferências de zona no IdM CLI, consulte Habilitação de transferências de zona no IdM CLI.
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
-
Na interface web da IdM, clique em
Network Services
→DNS
→DNS Zones
. -
Clique em
Settings
. 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
- 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 comandoipa 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
SSH para um dos servidores DNS para o qual a transferência de zona foi habilitada:
$ ssh 192.0.2.1
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
- Para mais informações sobre como usar o Red Hat Ansible Engine para gerenciar zonas DNS IdM, consulte Como usar os playbooks Ansible para gerenciar zonas DNS IdM.
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:
- Que tipos de zona DNS são suportados na IdM
- Quais atributos DNS você pode configurar no IdM
- Como usar um caderno de exercícios possível para criar uma zona primária no DNS do IdM
- Como usar um caderno de exercícios para garantir a presença de uma zona DNS IdM primária com múltiplas variáveis
- Como usar um livro de jogo possível para garantir a presença de uma zona para pesquisa DNS reversa quando um endereço IP é dado
Pré-requisitos
- O serviço DNS é instalado no servidor da IdM. Para mais informações sobre como usar o Red Hat Ansible Engine para instalar um servidor IdM com DNS integrado, consulte Instalação de um servidor de Gerenciamento de Identidade usando um livro de exercícios Ansible playbook.
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.
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 comandosipa dnszone-*
.Em conformidade com as regras DNS padrão, cada zona primária deve conter registros
start of authority
(SOA) enameserver
(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 nomesub.test.example.
. Além disso, a zonatest.example.
é configurada com o endereço IP do reencaminhador192.0.2.254
para a subzonasub.text.example
.Um cliente que pergunta o nome
nonexistent.test.example.
recebe a respostaNXDomain
, 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 configurado192.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:
-
O comando
dnszone-mod
na interface de linha de comando (CLI). Para mais informações, consulte Editando a configuração de uma zona DNS primária no IdM CLI. - A IDM Web UI. Para mais informações, consulte Editando a configuração de uma zona DNS primária na Interface Web IdM.
-
Um caderno de exercícios possível que utiliza o módulo
ipadnszone
. Para mais informações, consulte Utilização de playbooks ansíveis para gerenciar zonas DNS IdM.
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
Atributo | variável ansible-freeipa | Descrição |
---|---|---|
Servidor de nomes autorizado |
| 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 |
Endereço de e-mail do administrador |
| 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 |
| 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 |
| 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 |
| Define o tempo, em segundos, para esperar antes de tentar novamente uma operação de atualização falhada. |
A SOA expira |
| 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 |
| Define o valor de tempo de vida (TTL) em segundos para cache negativo de acordo com a RFC 2308. |
Tempo de SOA para viver |
|
Define TTL em segundos para registros no ápice da zona. Na zona |
Tempo padrão para viver |
|
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 |
Política de atualização BIND |
| Define as permissões permitidas aos clientes na zona DNS. |
Atualização dinâmica |
| 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 |
| 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 |
Permitir consulta |
| 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 |
| 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 |
| 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 |
| 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 arquivoREADME-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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnszone
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
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
Faça uma cópia do arquivo do livro de jogo dnszone-present.yml. Por exemplo:
$ cp dnszone-present.yml dnszone-present-copy.yml
- Abra o arquivo dnszone-present-copy.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnszone.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnszone
. -
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnszone
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
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
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
- Abra o arquivo dnszone-all-params-copy.yml para edição.
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
, edefault_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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnszone.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnszone
. -
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnszone
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
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
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
- Abra o arquivo dnszone-reverse-from-ip-copy.yml para edição.
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.
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnszone.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnszone
. -
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:
- Seção 64.1, “As duas funções de um servidor DNS IdM”
- Seção 64.2, “Políticas de encaminhamento de DNS na IdM”
- Seção 64.3, “Adicionando um forwarder global na IDM Web UI”
- Seção 64.4, “Adicionando um forwarder global no CLI”
- Seção 64.5, “Adicionando uma Zona de Encaminhamento DNS na interface web do IdM”
- Seção 64.6, “Adicionando uma Zona de Encaminhamento DNS no CLI”
- Seção 64.7, “Estabelecendo um Encaminhador Global DNS na IdM usando o Ansible”
- Seção 64.8, “Garantindo a presença de um forwarder global DNS na IdM usando o Ansible”
- Seção 64.9, “Garantindo a ausência de um encaminhador global DNS na IdM usando o Ansible”
- Seção 64.10, “Garantindo que o DNS Global Forwarders seja desativado no IdM usando o Ansible”
- Seção 64.11, “Garantindo a presença de uma Zona de Encaminhamento DNS na IdM usando o Ansible”
- Seção 64.12, “Garantir que uma Zona de Encaminhamento DNS tenha vários encaminhadores na IdM usando o Ansible”
- Seção 64.13, “Assegurar que uma Zona de Encaminhamento DNS seja desativada no IdM usando o Ansible”
- Seção 64.14, “Garantindo a ausência de uma Zona de Encaminhamento DNS no IdM 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.
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
Na interface web da IdM, selecione
Network Services
→DNS Global Configuration
→DNS
.Na seção
DNS Global Configuration
, clique emAdd
.Especifique o endereço IP do servidor DNS que receberá as consultas DNS encaminhadas.
Selecione o
Forward policy
.-
Clique em
Save
na parte superior da janela.
Etapas de verificação
Selecione
Network Services
→DNS Global Configuration
→DNS
.Verifique se o forwarder global, com a política de forward que você especificou, está presente e habilitado na IDM Web UI.
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).
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
Na interface web da IdM, selecione
Network Services
→DNS Forward Zones
→DNS
.Na seção
DNS Forward Zones
, clique emAdd
.Na janela
Add DNS forward zone
, especifique o nome da zona de avanço.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.Selecione o
Forward policy
.-
Clique em
Add
na parte inferior da janela para adicionar a nova zona de avanço.
Etapas de verificação
Na interface web da IdM, selecione
Network Services
→DNS Forward Zones
→DNS
.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.
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).
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 fornone
, 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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
Faça uma cópia do arquivo do livro de jogo
set-configuration.yml
. Por exemplo:$ cp set-configuration.yml establish-global-forwarder.yml
-
Abra o arquivo
establish-global-forwarder.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to establish a global forwarder in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraCreate a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800
. Na seção
forwarders
da parteipadnsconfig
:-
Alterar o primeiro valor
ip_address
para o endereço IPv4 do forwarder global:8.8.6.6
. -
Altere o segundo valor
ip_address
para o endereço IPv6 do forwarder global:2001:4860:4860::8800
. -
Verifique se o valor
port
está definido para53
.
-
Alterar o primeiro valor
Mude o
forward_policy
parafirst
.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
-
Altere a variável
- Salvar o arquivo.
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 arquivoREADME-dnsconfig.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsconfig
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
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
-
Abra o arquivo
ensure-presence-of-a-global-forwarder.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure the presence of a global forwarder in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
. Na seção
forwarders
da parteipadnsconfig
:-
Alterar o primeiro valor
ip_address
para o endereço IPv4 do forwarder global:7.7.9.9
. -
Altere o segundo valor
ip_address
para o endereço IPv6 do forwarder global:2001:db8::1:0
. -
Verifique se o valor
port
está definido para53
.
-
Alterar o primeiro valor
Mude o
state
parapresent
.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
-
Altere a variável
- Salvar o arquivo.
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 arquivoREADME-dnsconfig.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsconfig
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
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
-
Abra o arquivo
ensure-absence-of-a-global-forwarder.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure the absence of a global forwarder in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
. Na seção
forwarders
da parteipadnsconfig
:-
Alterar o primeiro valor
ip_address
para o endereço IPv4 do forwarder global:8.8.6.6
. -
Altere o segundo valor
ip_address
para o endereço IPv6 do forwarder global:2001:4860:4860::8800
. -
Verifique se o valor
port
está definido para53
.
-
Alterar o primeiro valor
Verifique se o site
state
está configurado paraabsent
.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
-
Altere a variável
- Salvar o arquivo.
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 arquivoREADME-dnsconfig.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsconfig
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
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
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 arquivoREADME-dnsconfig.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsconfig
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
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
-
Abra o arquivo
ensure-presence-forwardzone.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure the presence of a dnsforwardzone in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure presence of a dnsforwardzone for example.com to 8.8.8.8
. -
Na seção
tasks
, altere o títuloipadnsconfig
paraipadnsforwardzone
. Na seção
ipadnsforwardzone
:-
Adicione a variável
ipaadmin_password
e configure-a para sua senha de administrador IdM. -
Adicione a variável
name
e configure-a paraexample.com
. Na seção
forwarders
:-
Remover as linhas
ip_address
eport
. Adicione o endereço IP do servidor DNS para receber pedidos encaminhados, especificando-o após um traço:
- 8.8.8.8
-
Remover as linhas
-
Adicione a variável
forwardpolicy
e configure-a parafirst
. -
Adicione a variável
skip_overlap_check
e configure-a paratrue
. -
Altere a variável
state
parapresent
.
Este é o arquivo Ansible playbook modificado para o exemplo atual:
-
Adicione a variável
--- - 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
-
Altere a variável
- Salvar o arquivo.
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 arquivoREADME-dnsforwardzone.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsforwardzone
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
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
-
Abra o arquivo
ensure-presence-multiple-forwarders.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure the presence of multiple forwarders in a dnsforwardzone in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure presence of 8.8.8.8 and 4.4.4.4 forwarders in dnsforwardzone for example.com
. -
Na seção
tasks
, altere o títuloipadnsconfig
paraipadnsforwardzone
. Na seção
ipadnsforwardzone
:-
Adicione a variável
ipaadmin_password
e configure-a para sua senha de administrador IdM. -
Adicione a variável
name
e configure-a paraexample.com
. Na seção
forwarders
:-
Remover as linhas
ip_address
eport
. 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
-
Remover as linhas
- Mude a variável de estado para apresentar.
Este é o arquivo Ansible playbook modificado para o exemplo atual:
-
Adicione a variável
--- - 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
-
Altere a variável
- Salvar o arquivo.
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 arquivoREADME-dnsforwardzone.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsforwardzone
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
Faça uma cópia do arquivo do livro de jogo
forwarders-absent.yml
. Por exemplo:$ cp forwarders-absent.yml garantir-desabilitar-zona.yml
-
Abra o arquivo
ensure-disabled-forwardzone.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure a dnsforwardzone is disabled in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure a dnsforwardzone for example.com is disabled
. -
Na seção
tasks
, altere o títuloipadnsconfig
paraipadnsforwardzone
. Na seção
ipadnsforwardzone
:-
Adicione a variável
ipaadmin_password
e configure-a para sua senha de administrador IdM. -
Adicione a variável
name
e configure-a paraexample.com
. -
Remover toda a seção
forwarders
. -
Altere a variável
state
paradisabled
.
Este é o arquivo Ansible playbook modificado para o exemplo atual:
-
Adicione a variável
--- - 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
-
Altere a variável
- Salvar o arquivo.
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 arquivoREADME-dnsforwardzone.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsforwardzone
.
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
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 configurarserver.idm.example.com
, entre:[ipaserver] server.idm.example.com
Faça uma cópia do arquivo do livro de jogo
forwarders-absent.yml
. Por exemplo:$ cp forwarders-absent.yml garantir-absence-forwardzone.yml
-
Abra o arquivo
ensure-absence-forwardzone.yml
para edição. Adapte o arquivo, definindo as seguintes variáveis:
-
Altere a variável
name
paraPlaybook to ensure the absence of a dnsforwardzone in IdM DNS
. -
Na seção
tasks
, altere oname
da tarefa paraEnsure the absence of a dnsforwardzone for example.com
. -
Na seção
tasks
, altere o títuloipadnsconfig
paraipadnsforwardzone
. Na seção
ipadnsforwardzone
:-
Adicione a variável
ipaadmin_password
e configure-a para sua senha de administrador IdM. -
Adicione a variável
name
e configure-a paraexample.com
. -
Remover toda a seção
forwarders
. -
Deixe a variável
state
comoabsent
.
Este é o arquivo Ansible playbook modificado para o exemplo atual:
-
Adicione a variável
--- - 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
-
Altere a variável
- Salvar o arquivo.
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 arquivoREADME-dnsforwardzone.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsforwardzone
.
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
Sua implantação de IdM contém um servidor DNS integrado. Para informações sobre como instalar o IdM com DNS integrado, veja um dos links a seguir:
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 valorIP Address
de um registro A é um endereço IPv4, tal como192.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 valorIP Address
é um endereço IPv6, tal como2001: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._protocol
como, 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.
NotaTodas 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ínioin-addr.arpa.
anexado a ele. Por exemplo, para o endereço de rede192.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.
NotaTambé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
-
Na interface web da IdM, clique em
Network Services
→DNS
→DNS Zones
. - Clique na zona DNS na qual você deseja adicionar um registro DNS.
Na seção
DNS Resource Records
, clique em Adicionar para adicionar um novo recorde.Figura 65.1. Adicionando um novo registro de recursos DNS
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
- 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
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
Option | Description |
---|---|
| Define o tempo para viver para o registro. |
| Analisa os registros DNS brutos e os devolve em um formato estruturado. |
Tabela 65.2. \Opções de discos "A"
Option | Description | Examples |
---|---|---|
| Passa um único registro A ou uma lista de registros A. |
|
Pode criar um wildcard Um registro com um determinado endereço IP. |
| |
|
Fornece o endereço IP para o registro. Ao criar um registro, a opção para especificar o valor do registro |
|
[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
Option | Description | Example |
---|---|---|
| Passa um único registro AAAA (IPv6) ou uma lista de registros AAAA. |
|
|
Fornece o endereço IPv6 para o registro. Ao criar um registro, a opção para especificar o valor do registro |
|
Tabela 65.4. "\Opções de registro "PTR
Option | Description | Example |
---|---|---|
|
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 |
|
| ||
| Dá o nome do anfitrião para o registro. |
Tabela 65.5. "SRV Opções de registro
Option | Description | Example |
---|---|---|
|
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 |
|
| ||
| 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. |
|
| 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. |
|
| Dá o porto para o serviço no anfitrião alvo. |
|
| 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 comandoipa 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
-
Na interface web da IdM, clique em
Network Services
→DNS
→DNS Zones
. - Clique na zona da qual você deseja excluir um registro DNS, por exemplo example.com..
Na seção
DNS Resource Records
, clique no nome do registro do recurso.Figura 65.3. Seleção de um registro de recursos DNS
- Selecione a caixa de seleção com o nome do tipo de registro a ser apagado.
Clique em
Delete
.Figura 65.4. Eliminação de um registro de recursos DNS
O tipo de registro selecionado é agora excluído. A outra configuração do registro do recurso é deixada intacta.
Recursos adicionais
- Para mais informações sobre como excluir um registro DNS inteiro, consulte Excluindo um registro DNS inteiro na interface web do IdM.
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
-
Na interface web da IdM, clique em
Network Services
→DNS
→DNS Zones
. - Clique na zona da qual você deseja excluir um registro DNS, por exemplo zone.example.com..
-
Na seção
DNS Resource Records
, selecione a caixa de seleção do registro do recurso a ser excluído. Clique em Excluir.
Figura 65.5. Eliminação de um registro completo de recursos
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 comandoipa dnsrecord-del --help
.
65.8. Recursos adicionais
-
Você pode usar o módulo
ansible-freeipa
ipadnsrecord
para adicionar, modificar e excluir registros no DNS do IdM. Para mais informações, consulte Utilizando o Ansible to manage DNS records in IdM.
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:
- Garantir a presença de registros DNS A e AAAA na IdM usando o Ansible
- Garantir a presença de registros DNS A e PTR na IdM usando o Ansible
- Garantir a presença de múltiplos registros DNS na IdM usando o Ansible
- Garantindo a presença de múltiplos registros CNAME na IdM usando o Ansible
- Garantir a presença de um registro SRV na IdM usando o Ansible
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
- 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.
Procedimento
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra o arquivo ensure-A-and-AAAA-records-are-present-copy.yml para edição.
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ávelname
para host1, e a variávela_ip_address
para 192.168.122.123. Na variável
records
, defina a variávelname
para host1, e a variávelaaaa_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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnsrecord.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsrecord
. -
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra o arquivo ensure-dnsrecord-with-reverse-is-present-copy.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnsrecord.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsrecord
. -
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
- 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.
Procedimento
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra o arquivo ensure-presence-multiple-records-copy.yml para edição.
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ávelname
para host1. -
Na seção
records
, defina a variávelzone_name
para idm.example.com. -
Na seção
records
, defina a variávela_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:
-
Defina a variável
--- - 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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnsrecord.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsrecord
. -
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
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra o arquivo ensure-CNAME-record-is-present-copy.yml para edição.
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:
-
Defina a variável
--- - 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
-
(Opcional) Adaptar a descrição fornecida pelo
- Salvar o arquivo.
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 arquivoREADME-dnsrecord.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsrecord
. -
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
- 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.
Procedimento
Navegue até o diretório
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra o arquivo ensure-SRV-record-is-present-copy.yml para edição.
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
-
Defina a variável
- Salvar o arquivo.
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 arquivoREADME-dnsrecord.md
Markdown, disponível no diretório/usr/share/doc/ansible-freeipa/
. O arquivo também contém as definições das variáveisipadnsrecord
. -
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.
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
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.
Inicie o cronômetro
systemd
:# systemctl start ipa-healthcheck.timer
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.
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/
.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ã.
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
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
ondeid_provider=ipa
garante queipa_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 deipa 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ídasssctl 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 pluginsIPA SIDGEN
eipa-sidgen-task
emcn=plugins,cn=config
incluem a opçãonsslapd-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 listanet 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.
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çãocert_expiration_days
localizada na seção padrão.NotaA 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.NotaEste 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
edogtag-ipa-ca-renew-agent-reuse
que renovam os certificados do subsistema CA.
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
contraca.audit_signing.cert
-
ocspSigningCert cert-pki-ca
contraca.ocsp_signing.cert
-
caSigningCert cert-pki-ca
contraca.signing.cert
-
subsystemCert cert-pki-ca
contraca.subsystem.cert
-
Server-Cert cert-pki-ca
contraca.sslserver.cert
Se a Key Recovery Authority (KRA) estiver instalada:
-
transportCert cert-pki-kra
contraca.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).
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 teste | Mínimo espaço em disco em MB |
---|---|
| 1024 |
| 512 |
| 1024 |
| 512 |
| 512 |
| 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
-
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
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.
NotaO 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=*))
.
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.
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.
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çãoRed 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.
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
Instalar os pacotes necessários:
[root@ipaserver ~]#
yum install ipa-server ipa-server-trust-ad samba-client
Autenticar como usuário administrativo da IdM:
[root@ipaserver ~]#
kinit admin
Execute o utilitário
ipa-adtrust-install
:[root@ipaserver ~]#
ipa-adtrust-install
Os registros do serviço DNS são criados automaticamente se a IdM foi instalada com um servidor DNS integrado.
Se o IdM foi instalado sem um servidor DNS integrado,
ipa-adtrust-install
imprime uma lista de registros de serviços que devem ser adicionados manualmente ao DNS antes que você possa continuar.O roteiro lhe pede que o
/etc/samba/smb.conf
já existe e será reescrito:WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration. Do you wish to continue? [no]:
yes
O script solicita que você configure o plug-in
slapi-nis
, um plug-in de compatibilidade que permite que clientes Linux mais antigos trabalhem com usuários confiáveis:Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]:
yes
Quando solicitado, digite o nome NetBIOS para o domínio IdM ou pressione Enter para aceitar o nome sugerido:
Trust is configured but no NetBIOS domain name found, setting it now. Enter the NetBIOS name for the IPA domain. Only up to 15 uppercase ASCII letters, digits and dashes are allowed. Example: EXAMPLE. NetBIOS domain name [IDM]:
Você é solicitado a executar a tarefa da geração SID para criar um SID para qualquer usuário existente:
Você quer executar a tarefa ipa-sidgen? [não]
yes
Quando o diretório é instalado pela primeira vez, pelo menos um usuário (o administrador do IdM) existe e como esta é uma tarefa de recursos intensivos, se você tiver um alto número de usuários, você pode executá-la em outro momento.
(Optional) Por padrão, a faixa de portas Dynamic RPC é definida como
49152-65535
para Windows Server 2008 e posteriores. Se você precisar definir uma faixa de portas Dynamic RPC diferente para seu ambiente, configure o Samba para usar diferentes portas e abra essas portas em suas configurações de firewall. O exemplo a seguir define o intervalo de portas para55000-65000
.[root@ipaserver ~]#
net conf setparm global 'rpc server dynamic port range' 55000-65000
[root@ipaserver ~]#firewall-cmd --add-port=55000-65000/tcp
[root@ipaserver ~]#firewall-cmd --runtime-to-permanent
Reinicie o serviço
ipa
:[root@ipaserver ~]#
ipactl restart
Use o utilitário
smbclient
para verificar se o Samba responde à autenticação Kerberos do lado do IdM:[root@ipaserver ~]#
smbclient -L server.idm.example.com -k
lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.12.3) ...
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
-
Abra o
Group Policy Management Console
. -
Clique com o botão direito do mouse
Default Domain Policy
, e selecioneEdit
. OGroup Policy Management Editor
abre. -
Navegue para
Computer Configuration
Security Options
Policies
→Windows Settings
→Security Settings
Local Policies
→ → → . -
Clique duas vezes na política
Network security: Configure encryption types allowed for Kerberos
. -
Selecione
AES256_HMAC_SHA1
e, opcionalmente,Future encryption types
. - Clique OK.
-
Feche o
Group Policy Management Editor
. -
Repita os passos para o
Default Domain Controller Policy
. 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
- Tanto os servidores da IdM quanto o cliente devem rodar no RHEL 8.1 ou posterior.
-
O domínio IdM é preparado como descrito em Preparando o domínio IdM para instalar o Samba nos membros do domínio na documentação
Deploying different types of servers
... -
Se a IdM tiver uma confiança configurada com AD, habilite o tipo de criptografia AES para Kerberos. Por exemplo, use um objeto de política de grupo (GPO) para habilitar o tipo de criptografia AES. Para detalhes, veja Habilitar a criptografia AES no Active Directory usando uma GPO na documentação
Deploying different types of servers
.
Procedimento
Instale o pacote
ipa-client-samba
:[root@idm_client]#
yum install ipa-client-samba
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 servicesPor 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
Compartilhar diretórios e impressoras. Para detalhes, veja as seguintes seções na documentação
Deploying different types of servers
para RHEL 8: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
Habilitar e iniciar os serviços
smb
ewinbind
:[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:
Autenticar e obter um ingresso Kerberos para a concessão de bilhetes:
$
kinit example_user
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 manualipa-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
Autenticar usando o keytab do host:
[root@idm_client]#
kinit -k
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ínioad.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
eipaidrangesize
nos próximos passos.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).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.Reinicie os serviços
smb
ewinbind
:[root@idm_client]#
systemctl restart smb winbind
Etapas de verificação
Autenticar como usuário do novo domínio e obter um ticket de concessão de Kerberos:
$
kinit example_user
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
-
Para detalhes sobre como unir a RHEL 8 a um domínio IdM, veja o
Installing an Identity Management client
no guiaInstalling Identity Management
.
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
- Criação do domínio IdM. Para mais informações, consulte Instalando o Gerenciamento de Identidade.
- Cliente IPA instalado. Para mais informações, consulte Instalando pacotes ipa-cliente.
Procedimento
Se algum de seus clientes NFS suportar apenas criptografia fraca, como os clientes do Red Hat Enterprise Linux 5:
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
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
Obter um bilhete Kerberos:
[root@nfs-server ~]# kinit admin
- 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.
Criar a entrada de serviço NFS:
[root@nfs-server ~]# ipa service-add nfs/nfs-server.example.com
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.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
Instale o nfs-utils pacote:
[root@nfs-server ~]# yum instalar nfs-utils
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.Edite o arquivo
/etc/exports
e adicione ações com a configuração de segurançakrb5p
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.Reinicie e ative o nfs-server:
[root@nfs-server ~]# systemctl restart nfs-server [root@nfs-server ~]# systemctl enable nfs-server
Reexportar os diretórios compartilhados:
[root@nfs-server ~]# exporttfs -rav
- 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
- Criação do domínio IdM. Para mais informações, consulte Instalando o Gerenciamento de Identidade.
- Cliente IPA instalado. Para mais informações, consulte Instalando pacotes ipa-cliente.
Procedimento
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
- 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.
Instale o nfs-utils pacote:
[root@nfs-client ~]# yum instalar nfs-utils
Obter um bilhete Kerberos antes de executar as ferramentas IdM.
[root@nfs-client ~]# kinit admin
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âmetroDomain
no arquivo/etc/idmapd.conf
.Adicione as seguintes entradas ao arquivo
/etc/fstab
para montar as ações do NFS do hostnfs-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
.- Criar os pontos de montagem, se eles não existirem. Em nosso caso, ambos deveriam existir.
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
.Configurar o SSSD para renovar os bilhetes da Kerberos:
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
Reinicie o SSSD:
[root@nfs-client ~]# systemctl restart sssd
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.