Você precisa adicionar debug_level = 10 em todas as seções do arquivo sssd.conf, reiniciar o sssd e executar novamente o login. Então olhe em / var / log / sssd. Além disso, leia o link
Como um depurar corretamente o login do shell no seguinte caso?
A autenticação é feita via configuração sssd e um servidor de autenticação krb5. Logar com o mesmo arquivo .conf no Ubuntu 16.04 LTS funciona perfeitamente. Uma vez que o use com o 17.04, o login com tudo que não seja raiz resulta no getty connect sendo reiniciado - estados / var / log / syslog
[email protected]: Service has no hold-off time, sheduling restert.
Stopped Getty on tty2.
Started Getty on tty2.
e no auth.log o seguinte é anotado:
pam_sss(login:account): Access denied for user <user>: 4 (System error)
System error
Executar login <user> resulta em
root@pctest# login <user>
password:
System error
root@pctest#
O uso de sssctl config-check resulta em nenhum erro conforme esperado da configuração de trabalho em 16.04 LTS.
Todos os testes que mencionei foram realizados em sistemas configurados automaticamente e verificados manualmente, instalados recentemente em unidades formatadas. Pacotes adicionais foram instalados através do ubuntu-standard metapackage (nenhum ambiente de desktop instalado). No entanto, o problema também foi reproduzido em um sistema 16.04 LTS atualizado para 17.04.
Eu não encontrei um modo detalhado para login nem uma maneira razoável de executar a parte com falha do login como autônoma. Então, o que você faria?
[Editar] Solução alternativa de trabalho
Uma solução para o problema dado é:
Workaround for us was to set ad_gpo_access_control = permissive in the [domain] section of file /etc/sssd/sssd.conf ...
Fonte: link
Você precisa adicionar debug_level = 10 em todas as seções do arquivo sssd.conf, reiniciar o sssd e executar novamente o login. Então olhe em / var / log / sssd. Além disso, leia o link