Bloqueando a conta de um usuário localmente quando o kerberos está habilitado

Question

Estou tentando configurar contas gerenciadas pelo Chef para um grupo de computadores com as seguintes características:

• Se não houver uma conta local, o login será bloqueado.
• Se houver uma conta local com chaves SSH, é possível usá-las para autenticação.
• Se houver uma conta local que tenha uma senha local, essa senha será usada para autenticação.
• Se houver uma conta local sem senha local, o Kerberos será usado.

Eu tenho muito trabalho.

Mas a última coisa que desejo fazer é desativar o login na conta bloqueando localmente a senha (por exemplo, usando usermod -L ). O problema é que quando a senha local é bloqueada, o PAM está voltando para o Kerberos ... e permitindo o acesso.

Existe uma maneira de configurar o PAM de forma que, se uma senha local existir, mas esteja bloqueada, ela não tentará o Kerberos?

O melhor que consigo pensar até agora é travar a conta, destruindo a senha local com algo que não é possível julgar. Mas isso é um pouco grosseiro e não funciona bem se alguém não "segue o procedimento" ...

    

Answer 1

Concordo com os comentários de Michael Hampton - você pode e deve usar o Kerberos para fazer isso. Mas se você quiser fazer isso alterando as coisas na máquina local, aqui está uma solução que deve funcionar.

No seu sshd_config , adicione a linha

DenyGroups blocked

Crie um grupo chamado "bloqueado". Ao bloquear a senha local do usuário, adicione-a ao grupo "bloqueado".

ATENÇÃO! Este é um kludge terrivelmente feio que não deveria existir em um mundo são. Pode, no entanto, ser útil naquele em que vivemos.

    

Answer 2

Esse problema é principalmente uma consequência do fato de que pam_unix.so verifica os bloqueios de conta na pilha auth em vez de account , o que é um pouco contra-intuitivo para novatos do PAM. Decisões de contabilidade devem ser feitas em account , não auth , mas os bloqueios de conta baseados em sombra são executados com base no campo de senha. Isso faz com que seja um compromisso necessário.

Antes de continuar e decidir como implementar sua correção, vamos analisar os grupos de gerenciamento definidos pelo PAM:

• auth - Preocupações de autenticação. Limite seus ajustes às decisões com base nas credenciais que o usuário está enviando para autenticar, especialmente porque os programas podem optar por ignorar este módulo completamente se implementarem seu próprio esquema de autenticação. (o exemplo todo mundo esquece: sshd ignora auth se a autenticação por chave SSH estiver ativada e for bem-sucedida)
• account - O que a maioria das pessoas novas no PAM ignoram. Se a autenticação foi bem-sucedida , mas o acesso do usuário deve ser negado de qualquer maneira, essa decisão deve ser tomada aqui. ( sshd não pulará este módulo se a autenticação da chave SSH for bem-sucedida, ao contrário de auth )
• passwd - Alterando as senhas relacionadas aos serviços que você definiu em auth .
• session - Tarefas diversas que geralmente têm pouco a ver com o sucesso ou não da autenticação. Logging, material de montagem, etc.

Com base na descrição do seu problema:

1. Precisamos de uma pilha auth que priorize credenciais locais sobre credenciais krb5, mas uma delas deve ser bem-sucedida. Parece que você tem isso coberto.
2. Precisamos de uma pilha account que nega acesso se nenhum usuário local estiver definido. Como dito anteriormente, pam_unix.so nos falha a esse respeito.
3. Os passwd defaults provavelmente são bons para alterar as senhas locais.
4. Não temos motivo imediato para tocar em session .

Com base na sua proposta de auto-resposta, parece que você tem uma ideia de onde levá-la daqui.

    

Answer 3

Eu preciso verificar isso no trabalho, mas eu acho que eu poderia adicionar uma entrada "pam_exec" à pilha após a entrada "pam_krb5". Isso pode executar um script que use "passwd -S" para verificar se a entrada da senha do usuário não foi bloqueada.

Ou eu poderia fazer isso colocando o usuário em um grupo "bloqueado" e usando o pam_succeed_if assim:

auth required pam_succeed_if.so quiet_success user notingroup blocked

    

Answer 4

Para uso geral, não recomendo misturar contas locais e kerberos. No entanto, essa pilha de pam de autenticação deve funcionar para nossos propósitos. (Você pode ter outra peça, por exemplo, pam_env.so que você incluirá.)

auth     requisite     pam_unix.so nullok
auth     sufficient    pam_krb5 ignore_root use_first_pass
auth     required      pam_deny.so

Se a senha local do usuário estiver incorreta ou bloqueada, a autenticação falhará. Se o usuário não tiver uma senha local, a autenticação usará kerberos (não GSSAPI), se isso falhar, a autenticação falhará.