No xenial, a tela de bloqueio não funciona para mim. Independentemente de eu inserir a senha correta ou não, ela não me deixará entrar. No entanto, se eu clicar no menu no canto superior direito da tela e escolher "alternar usuário", mas escolher o mesmo usuário da tela de bloqueio isso me deixa entrar.
Na tela de bloqueio, a autenticação parece funcionar corretamente. Simplesmente não me autoriza. Aqui está o que vejo em /var/log/auth.log:
May 3 11:57:44 hostname compiz: pam_krb5(unity:auth): user myuser authenticated as [email protected]
May 3 11:57:44 hostname compiz: gkr-pam: unlocked login keyring
May 3 11:57:44 hostname compiz: pam_sss(unity:account): Access denied for user myuser: 6 (Permission denied)
A autenticação é de um domínio do Active Directory. Estou usando SSD. Essa mesma configuração funciona bem em Trusty, Vivid e Wily. Parece estar quebrado apenas no Xenial. Eu tentei em uma estação de trabalho que foi atualizada do Wily, bem como em uma nova instalação. Estou tendo muita dificuldade para descobrir o que precisa ser feito de maneira diferente.
Somente contas AD são afetadas por isso. As contas locais não são.
Ele também falha ao executar algo através da interface gráfica que requer privilégios elevados. Por exemplo, ao instalar software do Ubuntu Software Center. Não permitirá que uma conta do AD autorize a instalação, mas permitirá que um usuário local a autorize. No entanto, na linha de comando, as contas do AD podem usar o sudo sem problemas.
Algo está deixando Pam infeliz. Alguma ideia do que poderia ser?
Responder1
Esta correção foi postada como um comentário ao bug enviado por vargax. Se você adicionar:
ad_gpo_map_interactive = +unity
para a seção [domain/domainname] de /etc/sssd/sssd.conf, o problema da tela de bloqueio desaparece.
Infelizmente, isso não resolve o problema com privilégios elevados na GUI.
Responder2
Esses são dois bugs separados (mas provavelmente relacionados). Ninguém postou um log que demonstre o erro dos privilégios elevados, então não posso dizer qual opção adicionar ao sssd.conf para corrigi-lo.
Recebi "unidade" de "pam_sss(unity:account): Acesso negado" (o texto antes de ":account" é o nome do serviço PAM que está sendo contatado).
O bug aqui é que o mantenedor downstream do Ubuntu não ajustou o conjunto padrão de valores para o provedor AD para incluir qualquer serviço PAM em uso aqui e nega por padrão se for desconhecido.
Esta ad_gpo_map_interactive = +unity
é uma solução alternativa; Enviei um patch ao SSSD upstream para adicionar isso por padrão. Eu poderia fazer o mesmo com o que quer que esteja afetando os privilégios elevados, se não entrar em conflito com mais nada. Caso contrário, será responsabilidade do Ubuntu modificar isso no pacote downstream.
Responder3
Verifique se /etc/fstab está configurado corretamente para as partições do disco.
Então eu reconfiguraria o próprio lightdm
Para último recurso, eu tentaria reinstalar o próprio Ubuntu buscando as configurações de usuário e senha durante a instalação.
PAM parece ser muito complicado.
Responder4
Acabei de enviar um relatório de bug:https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1578415
Talvez vocês possam se marcar como afetados...