Como corrigir falhas de autenticação PAM no SUSE Linux Enterprise Server

Uma mensagem de “falha na autenticação PAM” nem sempre significa que a senha está incorreta. No SUSE Linux Enterprise Server (SLES), os Módulos de Autenticação Conectáveis ​​(PAM) formam uma pilha que verifica a identidade, o acesso à conta, as alterações de senha e a configuração da sessão. Uma falha pode ser causada por um erro de digitação ou uma conta desativada, um arquivo PAM corrompido, um serviço LDAP ou Active Directory indisponível, um problema com o relógio Kerberos ou DNS, ou um problema na sessão da área de trabalho que ocorre após a autenticação.

A solução mais segura é identificar qual serviço e qual estágio do PAM falharam antes de alterar a configuração. Este guia utiliza a documentação do SUSE Linux Enterprise Server 15 SP7 como referência. Se você estiver executando outro pacote de serviços do SLES ou uma imagem de appliance especializada, verifique a documentação correspondente do SUSE e as versões dos pacotes instalados antes de aplicar os comandos.

Primeiro, o que está falhando: um serviço específico ou todos os logins?

Registre o usuário, o horário exato, o host e o ponto de entrada da falha: SSH, console de texto local, login gráfico suou um aplicativo. Teste com uma segunda conta conhecida, se possível. Se apenas o SSH falhar, enquanto o login pelo console funcionar, concentre-se /etc/pam.d/sshdno serviço SSH. Se os usuários locais funcionarem, mas os usuários do diretório falharem, investigue o SSSD, LDAP, Active Directory, Kerberos, DNS ou a política de autorização do host. Se um login pelo console for bem-sucedido, mas a área de trabalho rejeitar o usuário ou retornar à tela de login, a falha pode estar na sessão gráfica ou no diretório inicial, e não na autenticação por senha.

Mantenha uma sessão root aberta durante a resolução de problemas. Se estiver conectado remotamente, mantenha uma segunda sessão SSH aberta e certifique-se de ter acesso ao console ou ao modo de recuperação antes de mexer no PAM. Um erro de sintaxe ou de parâmetro de controle em um arquivo PAM compartilhado pode bloquear novos logins para vários serviços.

1. Leia o diário sobre a tentativa fracassada.

O guia de solução de problemas da SUSE recomenda revisar o diário do sistema em busca de mensagens do processo de login e do PAM. Consulte um curto período de tempo próximo à falha para que mensagens não relacionadas não obscureçam a causa:

sudo journalctl -b --since "15 minutes ago"

Para um problema que envolva apenas SSH, restrinja a visualização ao daemon SSH:

sudo journalctl -b -u sshd --since "15 minutes ago"

Procure pelo nome do serviço, nome do serviço PAM, nome do módulo e se a mensagem se refere a auth, account, passwordou session. A pilha do PAM authverifica as credenciais; accountverifica se o usuário tem permissão para acessar esse serviço; sessionprepara o ambiente do usuário. Uma verificação de senha bem-sucedida seguida por uma negação de conta indica um problema diferente de um usuário desconhecido ou senha incorreta. Evite habilitar a depuração detalhada em um sistema de produção, a menos que seja necessário; os logs de diagnóstico podem conter nomes de contas e outros contextos confidenciais.

Consulte o guia de solução de problemas do SLES da SUSE para obter informações sobre o fluxo de trabalho de autenticação local e de rede.

2. Confirme se o SLES consegue encontrar o usuário.

Antes de alterar o PAM, verifique se o Name Service Switch do sistema consegue resolver a conta:

getent passwd user_name
id user_name

Substitua user_namepelo login afetado. Se esses comandos não retornarem nenhuma conta para um usuário do diretório, o PAM pode estar funcionando corretamente, mas a pesquisa de identidade está falhando. Verifique se o serviço de identidade configurado está em execução, se o host consegue acessar o diretório e se o usuário tem permissão para fazer login neste host. Para uma configuração baseada em SSSD, inspecione o daemon e os logs recentes:

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

A documentação da SUSE sobre o SSSD indica que ele oferece interfaces NSS e PAM e observa que pode armazenar dados de identidade em cache. Se os usuários relatarem falhas intermitentes, compare o horário e a resolução de DNS do sistema local com o diretório ou o ambiente Kerberos. O Kerberos depende da sincronização correta do horário; uma conexão de rede funcionando por si só não garante que a autenticação será bem-sucedida.

Verifique também se há conflitos de nomes. O SUSE lista um nome de usuário que existe localmente e em uma fonte de identidade de rede como uma possível causa de problemas de autenticação de rede. Verifique qual fonte de identidade deve ser a proprietária da conta antes de editar suas regras PAM.

3. Inspecione o arquivo de serviço PAM e a pilha compartilhada.

O SLES mantém arquivos PAM por serviço em /etc/pam.d. Um arquivo de serviço, como , /etc/pam.d/sshdgeralmente inclui arquivos compartilhados como common-auth, common-account, common-passworde common-session. Uma linha incorreta em um arquivo compartilhado pode afetar vários serviços; uma linha incorreta no arquivo de um aplicativo pode afetar apenas esse aplicativo.

Leia os arquivos relevantes e verifique seus links antes de editar:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

Verifique se há nomes de módulos com erros ortográficos, arquivos de módulos ausentes, opções incorretas, ordem inesperada e alterações feitas durante uma implementação recente de pacotes ou autenticação. Os sinalizadores de controle são importantes: requiredregistram uma falha, mas continuam a execução na pilha; requisitepodem parar imediatamente; sufficientpodem permitir que o sucesso retorne antecipadamente quando nenhum módulo necessário anterior falhou. Não copie uma pilha PAM de outra distribuição ou versão do SLES sem entender seus módulos e fluxo de controle.

Antes de alterar qualquer coisa, faça um backup somente com privilégios de root do diretório atual, preservando os links simbólicos:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

Confirme se o backup existe e registre exatamente quais arquivos você alterou. Se todos os usuários estiverem bloqueados, use o procedimento de recuperação do SLES e restaure a partir de uma configuração funcional conhecida, em vez de improvisar na tela de login.

4. No SLES, verifique se o pam-config gerencia os arquivos compartilhados.

A SUSE fornece um sistema pam-configpara manter os arquivos PAM globais e as configurações de aplicativos compatíveis. Geralmente, é mais seguro do que editar manualmente as pilhas compartilhadas geradas ao adicionar ou remover um método compatível. Primeiro, verifique os módulos disponíveis e a integração atual do SSSD:

sudo pam-config --list-modules
sudo pam-config --query --sss

Se o servidor usa o SSSD intencionalmente e a integração está faltando, a documentação da SUSE descreve sudo pam-config --add --ssscomo adicioná-la. Faça isso somente após confirmar o design de autenticação de diretório, revisar a pilha atual, manter o backup e garantir que você tenha uma rota de recuperação. Não execute este procedimento como uma solução genérica para toda "falha de autenticação". Consulte a configuração novamente e teste em uma segunda sessão.

Um comando particularmente arriscado é o ` sudo` pam-config --create. A SUSE afirma que ele gera uma configuração de autenticação Unix simples e sobrescreve os arquivos de configuração existentes que não são mantidos pelo sistema pam-config(mantendo cópias de segurança com um .pam-config-backupsufixo). Não se trata de um reparo de rotina para uma única falha de login. Use-o somente quando você tiver a intenção deliberada de reconstruir a configuração e tiver um plano de recuperação.

Se sua organização mantém arquivos PAM manualmente de forma intencional, siga esse padrão consistentemente. A SUSE observa que a configuração manual exige a desativação pam-configdesses arquivos. Pilhas personalizadas devem preservar os módulos de sessão necessários, incluindo -os pam_systemd.socomo módulos de sessão opcionais, quando aplicável.

5. Problemas separados de SSH, diretório e área de trabalho

Se apenas o SSH rejeitar a conta

Compare /etc/pam.d/sshdcom uma configuração SLES comprovadamente funcional e inspecione o registro (journal) do daemon SSH no momento da falha de login. Confirme se a conta está autorizada pelas configurações e controles de acesso do próprio SSH, bem como pelo PAM. Não enfraqueça a autenticação SSH nem remova as verificações de conta apenas para fazer o erro desaparecer.

Se apenas os usuários do diretório falharem

Confirme a pesquisa de conta com getent, verifique o status e os logs do SSSD e confirme a acessibilidade do diretório, DNS, sincronização de horário, registro do host e política de acesso do usuário. Se outro usuário do diretório tiver sucesso, compare os grupos, o shell, o diretório inicial e as regras de acesso específicas do host da conta afetada. O guia do cliente de autenticação da SUSE descreve o SSSD gerenciado pelo YaST e suas verificações de status.

Se o login no console funcionar, mas a sessão gráfica falhar

Verifique os registros de login e sessão da interface gráfica, a disponibilidade do diretório inicial, a propriedade, o espaço livre em disco e qualquer etapa de desbloqueio do diretório inicial criptografado. Um login bem-sucedido no console de texto é uma evidência útil de que a senha e o caminho de autenticação básica funcionam; isso direciona a atenção para a sessão da área de trabalho ou o ambiente do usuário. Evite excluir arquivos do usuário como primeiro passo. O guia de solução de problemas da SUSE recomenda isolar os problemas de configuração da área de trabalho metodicamente.

6. Verifique o reparo sem correr o risco de ficar bloqueado.

Após a alteração, abra uma nova sessão de teste enquanto o shell de recuperação permanecer disponível. Teste o serviço afetado com a conta afetada e, em seguida, teste com uma segunda conta e um administrador local. Para autenticação de diretório, confirme a pesquisa da conta e a integridade do serviço, bem como o login bem-sucedido. Verifique novamente o registro de erros PAM e remova quaisquer configurações de depuração temporárias com a pam-config --deleteopção correspondente quando o teste for concluído.

Por fim, confirme se o resultado resolve o problema em vez de apenas ocultá-lo. Um login corrigido deve autenticar o usuário pretendido, aplicar a política de conta desejada e criar uma sessão normal. Mantenha o backup até que você tenha verificado esses resultados e documentado a configuração final.

Quando você deve parar e usar o modo de resgate?

Pare de fazer alterações remotas se o acesso root for perdido, vários serviços falharem simultaneamente, a pilha compartilhada for sobrescrita ou você não conseguir determinar qual gerenciador de configuração é o proprietário dos arquivos. A documentação do SLES descreve o uso do acesso root para reparar a configuração e a entrada no modo de recuperação quando o login normal não estiver disponível. Para sistemas de produção gerenciados, envolva a equipe de identidade ou plataforma antes de reconstruir uma pilha de autenticação compartilhada.

Para obter informações precisas sobre a estrutura do arquivo PAM, os sinalizadores de módulo, pam-configo comportamento e as etapas de recuperação, consulte o guia PAM do SUSE SLES 15 SP7 e o guia de problemas comuns do SUSE , ambos correspondentes à sua versão. As pilhas PAM são políticas de segurança; faça a menor alteração justificada e, em seguida, verifique o acesso e as restrições.