O módulo PAM é desconhecido: qual processo falhou realmente

Leia essa frase como uma afirmação sobre um objeto partilhado e um ponteiro de função, não sobre uma palavra-passe. As mesmas palavras podem vir de um OpenVPN plugin, de uma pilha PAM carregada para um serviço ou de dentro do daemon RADIUS, e são três investigações diferentes. Escolha primeiro o processo.

As verificações abaixo partem do princípio de que a mensagem surgiu através de uma integração Linux-PAM num início de sessão VPN. Se veio da configuração do próprio servidor RADIUS, comece pelas provas desse daemon.

Nomeie o processo antes de nomear o pacote

Três componentes são chamados módulo e nenhum é permutável. Um plugin de autenticação OpenVPN é carregado pelo daemon VPN e implementa a interface de callback desse daemon. Um módulo PAM é um objeto partilhado que o libpam carrega para um serviço com nome, e que implementa pontos de entrada como pam_sm_authenticate. Um módulo FreeRADIUS é uma parte da configuração do próprio daemon. Uma mensagem com as mesmas palavras pode vir de qualquer um dos três, pelo que a primeira pergunta é que linha de registo a produziu.

Correlacione o carimbo temporal de uma tentativa falhada entre o registo VPN e o registo de autenticação do sistema e depois leia as linhas anteriores ao resumo. A mensagem específica do carregador está normalmente já lá.

Leia o erro de carregamento e depois o ponto de entrada

O PAM reporta um módulo desconhecido quando não consegue carregar o objeto partilhado selecionado, ou quando o objeto carregado não fornece a função que essa entrada da pilha exige. São reparações diferentes: a primeira é um problema de caminho, empacotamento ou ABI, e a segunda é um ponto de entrada que não corresponde. Uma linha de autenticação precisa de pam_sm_authenticate enquanto uma linha de conta precisa de pam_sm_acct_mgmt, e uma biblioteca que só implementa uma das duas falhará na outra, como o código do despachante mostra. Encontrar o ficheiro no disco não prova nenhuma das duas coisas.

Pegar numa biblioteca com um nome semelhante de outra distribuição ou arquitetura de CPU não é uma reparação, e pode deixar um processo a carregar um módulo que nunca foi testado contra o seu libpam. Verifique o pacote que possui o caminho pretendido e a arquitetura real do ficheiro antes de mudar seja o que for.

Mantenha as garantias que a pilha dava

A forma mais rápida de silenciar este erro é também a pior: marcar um módulo obrigatório como opcional, eliminar a fase de conta, ou inserir uma permissão incondicional. Cada uma transforma uma verificação falhada numa verificação ausente, e o início de sessão passa então por razões que ninguém pretendia. Repor palavras-passe e alterar segredos partilhados também não fornecem a função em falta, porque a falha ocorre antes de qualquer credencial chegar a um backend.

Uma pilha com vários módulos pode ter executado outro backend antes da entrada falhada, pelo que o erro não prova que não foi enviado qualquer pedido RADIUS.

Verifique o início de sessão, não o módulo

Depois de corrigida a discrepância, teste o verdadeiro caminho de admissão. Uma conta válida deve passar, credenciais inválidas devem continuar a falhar e uma conta proibida deve continuar a ser recusada. Confirme também que qualquer requisito de certificado ou fator adicional continua a ser aplicado, porque uma pilha reparada que salta uma fase parece um sucesso do lado do cliente.

Que um módulo carregue de forma limpa é progresso, não um teste concluído.

Registe que nome de serviço, que ficheiros de política e que pontos de entrada estiveram envolvidos, juntamente com a única tentativa que usou como prova. É esse registo que faz da ocorrência seguinte uma consulta e não um exercício de arqueologia.