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
.
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.
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.
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.
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.
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 dorid
ouad
ID em/etc/samba/smb.conf
, dependendo se a opção--automatic-id-mapping
foi configurada parasim
(padrão) ounã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 paraFalso
e o sistema usar os atributosuidNumber
egidNumber
do AD para o mapeamento de ID:-
Alterar a
configuração do idmap <domínio> : backend =
entradasss
no arquivo/etc/samba/smb.conf
paraidmap config <domínio> : backend = ad
-
Use o comando
systemctl status winbind
para reiniciar o Winbind.
-
Alterar a
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 comandodnf install keyutils
.
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
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.