Capítulo 3. Autenticação e Interoperabilidade
O Gerenciamento de Identidade estabelece uma relação de confiança unidirecional por padrão
O comando
ipa trust-add agora configura uma relação de confiança unidirecional por padrão. As relações de confiança unidirecionais permitem que os usuários e grupos no Active Directory (AD) acessem os recursos no Gerenciamento de Identidade (IdM), mas não o contrário. Anteriormente, a configuração de relação de confiança padrão, ao executar ipa trust-add, era uma relação bidirecional.
O IdM ainda permite, no entanto, que o administrador configure uma relação de confiança bilateral adicionando a opção
--two-way=true ao comando ipa trust-add.
Rebase do openldap para a versão 2.4.40
Os pacotes openldap foram atualizados para a versão upstream 2.4.40, a qual fornece várias correções de erros e um aprimoramento em relação à versão anterior. Em especial, a ORDENAÇÃO das regras de correspondência foi adicionada às descrições do tipo de atributo
ppolicy. Entre os erros corrigidos estão: o servidor não é mais encerrado de forma inesperada, durante o processamento dos registros SRV, e as informações objectClass ausentes foram adicionadas, permitindo ao usuário modificar a configuração front-end por meios convencionais.
Autenticação de cache em SSSD
A autenticação ao cache sem uma tentativa de reconexão está disponível agora em SSSD, mesmo em modo online. A autenticação direta ao servidor de rede de forma repetida pode causar uma latência excessiva ao aplicativo, deixando o processo de login bastante lento.
SSSD habilita o mapeamento do UID e GID em clientes individuais
Agora é possível mapear os usuários a um UID e GID diferente em certos clientes Red Hat Enterprise Linux através da configuração do lado do cliente, usando SSSD. Essa possibilidade de substituição do lado do cliente pode resolver os problemas causados pela duplicação do UID e GID ou facilitar a transição de um sistema legado que usava anteriormente um mapeamento de ID diferente.
Observe que as substituições ficam armazenadas no cache SSSD e a remoção do cache também remove as substituições.
SSSD pode negar acesso SSH a contas bloqueadas
Anteriormente, quando SSSD usava OpenLDAP como o seu banco de dados de autenticação, os usuários podiam autenticar-se no sistema com uma chave SSH com êxito, mesmo após a conta do usuário ter sido bloqueada. Agora, o parâmetro
ldap_access_order aceita o valor ppolicy , o qual pode negar acesso SSH ao usuário na situação descrita. Para mais informações sobre o uso de ppolicy, consulte a descrição ldap_access_order na página manual sssd-ldap(5).
O utilitário sudo é capaz de verificar o comando checksum (soma de verificação)
A configuração do utilitário sudo pode armazenar a soma de verificação de um comando ou script que está sendo permitido. Quando o comando ou script é executado novamente, a soma de verificação é comparada à soma de verificação armazenada para verificar se algo mudou. Se o comando ou binário for modificado, o utilitário sudo recusa a execução do comando ou registra um aviso. Esta funcionalidade possibilita transmitir as responsabilidades e atividades para a solução de problemas de forma adequada, caso ocorra um incidente.
Suporte SSSD ao cartão inteligente
O SSSD oferece suporte agora a cartões inteligentes para autenticação local. Com este recurso, o usuário pode usar um cartão inteligente para fazer log on no sistema utilizando um console gráfico ou baseado em texto, assim como serviços locais, como o serviço sudo. O usuário deve colocar o cartão inteligente no leitor e fornecer o nome do usuário e o código PIN do cartão no aviso de login. Se o certificado no cartão inteligente for verificado, o usuário é autenticado com êxito.
Observe que o SSSD não permite, atualmente, que o usário adquira um tíquete Kerberos utilizando um cartão inteligente. Para obter um tíquete Kerberos, o usuário ainda é solicitado a fazer a autenticação usando o utilitário kinit.
Suporte para múltiplos perfis de certificado e certificados de usuário
O Gerenciamento de Identidades oferece suporte agora a múltiplos perfis para a emissão de servidores e outros certificados, ao invés de oferecer suporte apenas a um único perfil de certificado de servidor. Os perfis são armazenados no Servidor de Diretório e compartilhado entre as réplicas do IdM.
Além disto, o administrador pode agora emitir certificados a usuários individuais. Anteriormente, era possível emitir certificados a hosts e serviços apenas.
Senha Vault
Um novo recurso foi adicionado ao Gerenciamento de Identidades para permitir um armazenamento central seguro das informações privadas do usuário, como senhas e chaves.
Kerberos HTTPS proxy no Gerenciamento de Identidades
Uma função proxy do Centro de Distribuição de Chaves (KDC), interoperável com a implementação do Protocolo Proxy Kerberos KDC da Microsoft (MS-KKDCP), está disponível agora no Gerenciamento de Identidades e permite aos clientes acessar os serviços
kpasswd e KDC usando HTTP. Os administradores de sistema podem expor o proxy na borda da rede através de um simples proxy reverso HTTP sem a necessidade de configurar e gerenciar um aplicativo em específico.
Atualização em segundo plano das entradas em cache
Agora, SSSD permite que as entradas em cache sejam atualizadas fora de banda em segundo plano. Antes desta atualização, quando a validade das entradas em cache expiravam, o SSSD analisava-as a partir do servidor remoto e armazenava-as no banco de dados outra vez, o que era um processo demorado. Com esta atualização, as entradas retornam instantaneamente, pois o back-end as mantém atualizadas todo o tempo. Observe que isto gera uma carga maior no servidor já que o SSSD baixa as entradas periodicamente e não apenas sob solicitação.
Cache para as operações initgroups
O cache de rápida memória SSSD agora oferece suporte às operações
initgroups, o que aumenta a velocidade do processamento de initgroups e melhora o desempenho de alguns aplicativos como, por exemplo, GlusterFS e slapi-nis.
Negociação de autenticação otimizada com mod_auth_gssapi
O Gerenciamento de Identidades emprega agora o módulo
mod_auth_gssapi, o qual usa chamadas GSSAPI ao invés de chamadas diretas Kerberos utilizadas pelo módulo mod_auth_kerb anteriormente empregado.
Recursos de gerenciamento do ciclo de vida do usuário
O gerenciamento do ciclo de vida do usuário fornece ao administrador um grande controle sobre a ativação e desativação das contas dos usuários. Agora, o administrador pode configurar novas contas de usuários adicionando-as a uma área de preparação que não as ativa por completo ou ativa as contas dos usuários inativas, deixando-as operacionais, ou ainda desativa as contas sem removê-las totalmente do banco de dados.
Os recursos de gerenciamento do ciclo de vida do usuário trazem importantes benefícios às implantações abrangentes do IdM. Observe que os usuários também podem ser adicionados à área de preparação diretamente de um cliente LDAP padrão, usando operações LDAP diretas. Anteriormente, o IdM oferecia suporte apenas ao gerenciamento de usuários utilizando as ferramentas da linha de comando do IdM ou da Interface do Usuário da web do IdM.
Suporte ao protocolo SCEP em certmonger
O serviço
certmonger foi atualizado para trazer suporte ao Protocolo de Registro de Certificado Simples (SCEP). Agora é possível emitir um novo certificado e renovar ou substituir os certificados existentes sobre o SCEP.
Os módulos Apache para IdM passam a ter suporte completo
Os seguintes módulos Apache para o Gerenciamento de Identidade (IdM), adicionados como Apresentação Prévia de Tecnologia no Red Hat Enterprise Linux 7.1, possuem, agora, suporte completo:
mod_authnz_pam, mod_lookup_identity e mod_intercept_form_submit. Os módulos Apache podem ser usados por aplicativos externos para obter interações mais próximas com o IdM para além da simples autenticação.
NSS aumenta os valores mínimos aceitáveis de restrição de chave
A biblioteca dos Serviços de Segurança de Redes (NSS) no Red Hat Enterprise Linux 7.2 não aceita mais parâmteros de troca de chaves Diffie-Hellman (DH) menores que 768 bits, nem os certificados RSA e DSA com tamanhos de chave com menos de 1023 bits. O aumento dos valores mínimos aceitáveis de restrição de chave evita ataques que exploram as vulnerabilidades de segurança conhecidas, como Logjam (CVE-2015-4000) e FREAK (CVE-2015-0204).
Observe que as tentativas de conexão com um servidor usando chaves mais fracas do que os novos valores mínimos resultam, agora, em falha, mesmo que tais conexões funcionassem nas versões prévias do Red Hat Enterprise Linux.
NSS habilita as versões 1.1 e 1.2 do TLS por padrão
Os aplicativos usando as versões de protocolo que o NSS habilita por padrão agora também fornecem suporte às versões 1.1 e 1.2 dos protocolos TLS.
Certificados ECDSA passam a ter suporte
Os aplicativos que usam a lista de codificação do NSS padrão agora fornecem suporte às conexões com os servidores que usam os certificados Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA).
OpenLDAP escolhe automaticamente os conjuntos de codificação padrão do NSS
Os clientes OpenLDAP agora escolhem automaticamente os conjuntos de codificação padrão dos Serviços de Segurança de Rede (NSS) para a comunicação com o servidor. Não é mais necessário manter os conjuntos de codificação padrão manualmente no código fonte do OpenLDAP.
A configuração de um servidor IdM para ser um agente de confiança passa a ter suporte
O Gerenciamento de Identidade (IdM) distingue dois tipos de servidores IdM mestre: controladores de confiança e agentes de confiança. Os controladores de confiança executam todos os serviços necessários para o estabelecimento e a manutenção de uma relação de confiança; os agentes de confiança executam apenas os serviços necessários para o fornecimento de resoluções de usuários e grupos de florestas do Active Directory confiáveis para os clientes IdM inscritos nestes servidores IdM.
Por padrão, a execução do comando
ipa-adtrust-install configura o servidor IdM como um controlador de confiança. Para configurar outro servidor IdM como um agente de confiança, acrescente a opção --add-agents ao comando ipa-adtrust-install.
A migração automatizada do WinSync para relações de confiança passa a ter suporte
O novo utilitário
ipa-winsync-migrate possibilita uma migração harmoniosa da integração baseada em sicronização usando WinSync para a integração baseada em relações de confiança do Active Directory (AD). O utilitário migra automaticamente todos os usuários sincronizados usando WinSync de uma floresta do AD. Anteriormente, a migração de sincronização para a relação de confiança podia ser realizada apenas manualmente, usando as visualizações de ID.
Para mais informações sobre
ipa-winsync-migrate, consulte a página manual ipa-winsync-migrate(1).
Solicitação de vários passos para as senhas de uso único e de longo prazo
Ao usar uma senha de uso único (token) junto com uma senha de longo prazo para a realização de login, o usuário recebe a solicitação para as duas senhas separadamente. Isto favorece o uso de senhas únicas assim como fornece uma extração da senha de longo prazo mais segura, permitindo que o cache da senha de longo prazo seja usado para autenticação offline.
Esquema LPK para OpenLDAP disponível no formato LDIF
LDIF é o novo formato padrão para o esquema de importação do OpenSDAP e o pacote openssh-ldap agora fornece o esquema de Chave Pública LDAP (LPK) no formato LDIF também. Assim, os administradores podem importar diretamente o esquema LDIF ao configurar a autenticação de chave pública baseada em LDAP.
Cyrus pode realizar a autenticação dos servidores IdM e AD novamente
Um lançamento upstream dos pacotes cyrus-sasl introduziu uma alteração não compatível com as versões anteriores que impedia o Cyrus de realizar a autenticação nas implementações SASL mais antigas. Como consequência, o Red Hat Enterprise Linux 7 não conseguia fazer a autenticação dos servidores AD e IdM do Red Hat Enterprise Linux 6. A alteração upstream foi revertida e o Cyrus agora é capaz de realizar a autenticação dos servidores AD e IdM como esperado.
SSSD fornece suporte à sobrescrição do site do AD descoberto automaticamente
O site do DNS do Active Directory (AD) com o qual o cliente conecta-se é descoberto automaticamente por padrão. No entanto, a pesquisa automática padrão pode não descobrir o site do AD mais adequado em determinadas configurações. Em tais situações, você pode definir agora o site DNS manualmente, usando o parâmetro
ad_site na seção [domain/NAME] do arquivo /etc/sssd/sssd.conf.
Suporte para SAML ECP
Os pacotes lasso foram rebaseados para a versão 2.5.0 e os pacotes mod_auth_mellon foram rebaseados para a versão 0.11.0 para adicionar suporte ao Security Assertion Markup Language (SAML) Enhanced Client or Proxy (ECP). O SAML ECP é um perfil SAML alternativo que permite Autenticações Únicas (SSO) não baseadas no navegador.
O serviço winbindd não lista mais as associações de grupos na sua configuração padrão
O serviço
winbindd na versão 4.2.0, ou posterior, do Samba não lista mais as associações de grupos para fins de exibição. Em algumas situações, como em ambientes com domínios confiáveis, não era sempre possível fornecer esta informação com segurança. Para impedir o risco do fornecimento de informações incorretas, a configuração padrão winbindd foi alterada para winbind expand groups = 0, o que desabilita o comportamento anterior. Observe que, alguns comandos, como getent group, dependiam anteriormente desta funcionalidade e podem não comportar-se como antes.
