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.
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.
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.
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.
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).
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
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].
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.