No Ubuntu 16.04, FreeIP ssh logins funcionando, logins GUI falha com “senha incorreta”

1

Eu tenho esse trabalho em uma máquina virtual, mas devo ter perdido a gravação de algo que instalei ou configurei, pois não consigo trabalhar em outras máquinas que eu criei. Eu estive cavando através do Google e aqui, mas a maioria das coisas que acabo vendo tem a ver com a exibição do campo de login "Outros ..." no greeter, ou fazer com que o FreeIPA funcione corretamente em primeiro lugar.

Passos que eu dou: Eu crio uma nova instalação do Ubuntu / Mate 16.04, faço todas as atualizações / upgrades, adiciono a máquina ao FreeIPA, instalo o freeipa-client, faço as configurações e executo o ipa-client-install, vejo que o novo A VM está inscrita corretamente no FreeIPA e, em seguida, testa por ssh em mim e em algumas outras máquinas com usuários que estão apenas no FreeIPA. Isso tudo funciona bem - eu posso ver os vários hosts sem usar FQDNs e usar usuários que não estão no arquivo passwd local.

No entanto, quando tento usar a GUI Mate para alternar usuários para um usuário no FreeIPA que pode efetuar login com êxito por meio do ssh (que, caso contrário, falhará rapidamente e retornará à tela de login, pois o usuário ainda não tem um diretório home), eu recebo o erro "Senha incorreta, por favor, tente novamente". O único usuário que pode efetuar login por meio dessa tela é o que defini localmente. Eu tentei criar um diretório home pertencente a um usuário FreeIPA apenas no caso, mas isso não faz diferença.

Então o ssh está resolvendo nomes que o lightdm ou algum outro componente no processo de login não é. O log lightdm mostra isso para um usuário "aluno", um usuário definido apenas no FreeIPA:

[+6783.50s] DEBUG: Continue authentication
[+6784.83s] DEBUG: Session pid=25854: Authentication complete with return value 0: Success
[+6784.83s] DEBUG: Authenticate result for user student: Success
[+6784.83s] DEBUG: User student authorized, but no account of that name exists
[+6784.84s] DEBUG: Greeter start authentication for student
[+6784.84s] DEBUG: Seat seat0: Failed to work out session ID to mark
[+6784.84s] DEBUG: Session pid=25872: Started with service 'lightdm', username 'student'
[+6784.84s] DEBUG: Session pid=25854: Exited with return value 0
[+6784.84s] DEBUG: Seat seat0: Session stopped
[+6784.85s] DEBUG: Session pid=25872: Got 1 message(s) from PAM
[+6784.85s] DEBUG: Prompt greeter with 1 message(s)

Isto é distintamente diferente da minha máquina Ubuntu / Mate, onde tudo está funcionando bem; lá, o log se parece com:

[+50005.95s] DEBUG: Continue authentication
[+50006.20s] DEBUG: Session pid=10425: Authentication complete with return value 0: Success
[+50006.20s] DEBUG: Authenticate result for user student: Success
[+50006.20s] DEBUG: User student authorized
[+50006.20s] DEBUG: Greeter sets language en_GB
[+50006.23s] DEBUG: Greeter requests session mate

Durante a falha, o log de autenticação mostra isso:

Aug 20 18:19:26 client2 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:1 ruser= rhost=  user=student
Aug 20 18:19:27 client2 lightdm: pam_sss(lightdm:auth): authentication success; logname= uid=0 euid=0 tty=:1 ruser= rhost= user=student
Aug 20 18:19:27 client2 lightdm: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory
Aug 20 18:19:27 client2 lightdm: PAM adding faulty module: pam_kwallet.so
Aug 20 18:19:27 client2 lightdm: PAM unable to dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared object file: No such file or directory
Aug 20 18:19:27 client2 lightdm: PAM adding faulty module: pam_kwallet5.so
Aug 20 18:19:27 client2 lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "student"

Tenho uma vaga impressão de que precisei adicionar algum pacote que garante que o LDAP seja contatado, mas depois de muita investigação, isso não revelou nada. Fico feliz em ter mais indicações de coisas para olhar ou conciliar entre o meu sistema de trabalho e o que não funciona, mas estou meio que perdendo aqui.

Essa pareceu ser uma causa plausível, mas não consigo encontrar nenhuma diferença em /etc/pam.d que aponte para o erro: link .

Isso toca alguma coisa para alguém?

    
por Haxsaw 21.08.2017 / 11:51

1 resposta

1

A resposta pode ser encontrada no site abaixo:

link

particularmente a seção sobre "Diretórios pessoais com o pam_mkhomedir (opcional)"

sessão requerida pam_mkhomedir.so skel = / etc / skel / umask = 0022

Eu adicionei isso após a chamada opcional para sssd de /etc/pam.d/common-session

    
por 27.10.2017 / 17:09