Red Hat Training

A Red Hat training course is available for RHEL 8

5.5.11. Gestão da Identidade

O cache de credenciais KCM não é adequado para um grande número de credenciais em um único cache de credenciais

O Gerente de Credenciais Kerberos (KCM) pode lidar com ccache de até 64 kB. Se ele contiver muitas credenciais, as operações Kerberos, tais como kinit, falham devido a um limite de código rígido no buffer usado para transferir dados entre o componente sssd-kcm e o banco de dados subjacente.

Para contornar este problema, adicione a opção ccache_storage = memory na seção kcm do arquivo /etc/sssd/sssd.conf. Isto instrui o kcm a responder a armazenar apenas as caches de credenciais em memória, não de forma persistente. Se você fizer isso, reiniciar o sistema ou sssd-kcm limpa os caches de credenciais.

(BZ#1448094)

A mudança /etc/nsswitch.conf requer uma reinicialização manual do sistema

Qualquer alteração no arquivo /etc/nsswitch.conf, por exemplo rodando o comando authselect select profile_id, requer uma reinicialização do sistema para que todos os processos relevantes usem a versão atualizada do arquivo /etc/nsswitch.conf. Se uma reinicialização do sistema não for possível, reinicie o serviço que une seu sistema ao Active Directory, que é o System Security Services Daemon (SSSD) ou winbind.

(BZ#1657295)

Valores de tempo limite conflitantes impedem que o SSSD se conecte aos servidores

Alguns dos valores padrão de timeout relacionados às operações de failover utilizadas pelo System Security Services Daemon (SSSD) são conflitantes. Consequentemente, o valor de timeout reservado ao SSSD para falar com um único servidor impede que o SSSD tente outros servidores antes da operação de conexão como um todo. Para contornar o problema, defina o valor do parâmetro ldap_opt_timeout maior que o valor do parâmetro dns_resolver_timeout, e defina o valor do parâmetro dns_resolver_timeout maior que o valor do parâmetro dns_resolver_op_timeout.

(BZ#1382750)

O SSSD só pode procurar certificados únicos nas anulações de identificação

Quando várias sobreposições de ID contêm o mesmo certificado, o System Security Services Daemon (SSSD) não consegue resolver consultas para os usuários que correspondem ao certificado. Uma tentativa de procurar esses usuários não devolve nenhum usuário. Observe que procurar usuários usando seu nome de usuário ou UID funciona como esperado.

(BZ#1446101)

O SSSD não lida corretamente com múltiplas regras de correspondência de certificados com a mesma prioridade

Se um determinado certificado corresponde a várias regras de correspondência de certificados com a mesma prioridade, o System Security Services Daemon (SSSD) utiliza apenas uma das regras. Como alternativa, use uma única regra de correspondência de certificado cujo filtro LDAP consiste nos filtros das regras individuais concatenadas com o | (ou) operador. Para exemplos de regras de correspondência de certificados, consulte a página de manual sss-certamp(5).

(BZ#1447945)

SSSD devolve a adesão incorreta ao grupo LDAP para usuários locais

Se o Serviço de Segurança do Sistema Daemon (SSSD) atende usuários de arquivos locais, o provedor de arquivos não inclui membros de grupo de outros domínios. Como conseqüência, se um usuário local é membro de um grupo LDAP, o comando id local_user não retorna a filiação do usuário ao grupo LDAP. Para contornar o problema, ou reverta a ordem dos bancos de dados onde o sistema está procurando a filiação em grupo de usuários no arquivo /etc/nsswitch.conf, substituindo arquivos sss por arquivos sss, ou desabilite o domínio de arquivos implícito, adicionando

enable_files_domain=False

para a seção [sssd] no arquivo /etc/sssd/sssd.conf.

Como resultado, id local_user retorna a adesão correta ao grupo LDAP para usuários locais.

(BZ#1652562)

As regras do sudo podem não funcionar com id_provider=ad se as regras do sudo referirem nomes de grupos

Daemon System Security Services (SSSD) não resolve nomes de grupos do Active Directory durante a operação do initgroups por causa de uma otimização da comunicação entre AD e SSSD usando um cache. A entrada do cache contém apenas um Identificador de Segurança (SID) e não nomes de grupos até que o grupo seja solicitado por nome ou ID. Portanto, as regras do sudo não correspondem ao grupo AD, a menos que os grupos sejam totalmente resolvidos antes da execução do sudo.

Para contornar este problema, você precisa desativar a otimização: Abra o arquivo /etc/sssd/sssd.conf e adicione o ldap_use_tokengroups = parâmetro falso na seção [domain/example.com].

(BZ#1659457)

As configurações padrão do PAM para o usuário do sistema foram alteradas no RHEL 8, o que pode influenciar o comportamento do SSSD

A pilha de módulos de autenticação Pluggable (PAM) mudou no Red Hat Enterprise Linux 8. Por exemplo, a sessão do usuário do sistema agora inicia uma conversa PAM usando o serviço PAM do usuário do sistema. Este serviço agora inclui recursivamente o serviço PAM system-auth, que pode incluir a interface pam_sss.so. Isto significa que o controle de acesso SSSD é sempre chamado.

Esteja ciente da mudança ao projetar regras de controle de acesso para os sistemas RHEL 8. Por exemplo, você pode adicionar o serviço de usuário do sistema à lista de serviços permitidos.

Observe que para alguns mecanismos de controle de acesso, tais como IPA HBAC ou AD GPOs, o serviço de usuário do sistema foi adicionado à lista de serviços permitidos por padrão e você não precisa tomar nenhuma ação.

(BZ#1669407)

O servidor IdM não funciona em FIPS

Devido a uma implementação incompleta do conector SSL para Tomcat, um servidor de Gerenciamento de Identidade (IdM) com um servidor de certificados instalado não funciona em máquinas com o modo FIPS habilitado.

(BZ#1673296)

Samba nega o acesso ao usar o plug-in de mapeamento de identificação sss

Para usar o Samba como um servidor de arquivos em um host RHEL unido a um domínio Active Directory (AD), o serviço Samba Winbind deve estar rodando mesmo que o SSSD seja usado para gerenciar usuários e grupos do AD. Se você entrar no domínio usando o comando join --client-software=sssd ou sem especificar o parâmetro --client-software neste comando, o reino cria apenas o arquivo /etc/sssd/sssd.conf. Quando você executa Samba no membro do domínio com esta configuração e adiciona uma configuração que usa o back end de mapeamento de ID sss ao arquivo /etc/samba/smb.conf para compartilhar diretórios, mudanças no back end de mapeamento de ID podem causar erros. Consequentemente, o Samba nega acesso aos arquivos em certos casos, mesmo que o usuário ou grupo exista e seja conhecido pelo SSSD.

Se você planeja atualizar de uma versão anterior do RHEL e o parâmetro ldap_id_mapping no arquivo /etc/sssd/sssd.conf estiver definido para True, que é o padrão, não há nenhuma solução de trabalho disponível. Neste caso, não atualize o host para RHEL 8 até que o problema tenha sido resolvido.

Possíveis soluções em outros cenários:

  • Para novas instalações, entre no domínio usando o comando join --client-software=winbind. Isto configura o sistema para usar Winbind em vez de SSSD para todas as buscas de usuários e grupos. Neste caso, o Samba usa o plug-in de mapeamento de ID do rid ou ad ID em /etc/samba/smb.conf, dependendo se a opção --automatic-id-mapping foi configurada para sim (padrão) ou não. Se você planeja usar SSSD no futuro ou em outros sistemas, usar --automatic-id-mapping=no permite uma migração mais fácil, mas requer que você armazene os POSIX UIDs e GIDs no AD para todos os usuários e grupos.
  • Ao atualizar de uma versão RHEL anterior, e se o parâmetro ldap_id_mapping no arquivo /etc/sssd/sssd.conf estiver configurado para Falso e o sistema usar os atributos uidNumber e gidNumber do AD para o mapeamento de ID:

    1. Alterar a configuração do idmap <domínio> : backend = entrada sss no arquivo /etc/samba/smb.conf para idmap config <domínio> : backend = ad
    2. Use o comando systemctl status winbind para reiniciar o Winbind.

(BZ#1657665)

O serviço nuxwdog falha em ambientes HSM e requer a instalação do pacote keyutils em ambientes não-HSM

O serviço nuxwdog watchdog foi integrado ao Sistema de Certificação. Como conseqüência, o nuxwdog não é mais fornecido como um pacote separado. Para usar o serviço watchdog, instale o pacote pki-server.

Observe que o serviço nuxwdog tem seguido os problemas conhecidos:

  • O serviço nuxwdog não funciona se você usar um módulo de armazenamento de hardware (HSM). Para esta questão, não há nenhuma solução disponível.
  • Em um ambiente não-HSM, o Red Hat Enterprise Linux 8.0 não instala automaticamente o pacote keyutils como uma dependência. Para instalar o pacote manualmente, use o comando dnf install keyutils.

(BZ#1652269)

A adição de anulações de ID de usuários AD funciona somente no IdM CLI

Atualmente, a adição de anulações de ID de usuários do Active Directory (AD) a grupos de Gerenciamento de Identidade (IdM) com a finalidade de conceder acesso a funções de gerenciamento falha na IDM Web UI. Para contornar o problema, use antes a interface de linha de comando (CLI) do IdM.

Note que se você instalou o pacote ipa-idoverride-memberof-plugin no servidor IdM depois de executar previamente certas operações usando o utilitário ipa, a Red Hat recomenda limpar o cache do utilitário ipa para forçá-lo a atualizar sua visão sobre os metadados do servidor IdM.

Para isso, remova o conteúdo do diretório ~/.cache/ipa para o usuário sob o qual o utilitário ipa é executado. Por exemplo, para root:

# rm -r /root/.cache/ipa

(BZ#1651577)

Nenhuma informação sobre os registros DNS necessários exibidos ao permitir o suporte à confiança do AD na IdM

Ao permitir o suporte à confiança do Active Directory (AD) na instalação do Red Hat Enterprise Linux Identity Management (IdM) com gerenciamento DNS externo, nenhuma informação sobre os registros DNS necessários é exibida. A confiança da floresta no AD não é bem sucedida até que os registros DNS requeridos sejam adicionados. Para contornar este problema, execute o comando 'ipa dns-update-system-records --dry-run' para obter uma lista de todos os registros DNS requeridos pelo IdM. Quando o DNS externo para o domínio IdM definir os registros DNS necessários, é possível estabelecer a confiança da floresta no AD.

(BZ#1665051)