Como usar o PAM para verificar a senha LDAP de alguns usuários, e sempre usar UID / GIDs de arquivos locais?

Question

Para um subconjunto de meus usuários em /etc/passwd , gostaria de configurar o PAM (no Linux) para fazer a verificação da senha em parte do logon em um servidor LDAP, ignorando que esses usuários estão na verdade listados como desativados em% código%. Especialmente, /etc/passwd e /etc/passwd devem ser usados em todos os casos para UID e GID, para que propriedades como /etc/group e uidnumber não precisem ser adicionadas ao diretório (aqui, Active Directory), diferentemente do que é normalmente mostrado na documentação, como HOWTO de implementação do LDAP .

Isso é possível (sem desenvolvimento de módulo PAM personalizado)? Não é possível adicionar propriedades ao diretório LDAP. Eu não sou o administrador de domínio do Active Directory e escalar o envolvimento para esse nível está fora do escopo deste projeto. É um caso em que o sistema está operacional em um ambiente que é principalmente servidores Windows; seria bom se usuários designados do Windows pudessem usar suas senhas do AD no sistema em questão.

Dependendo do usuário, o usuário deve ser verificado pela autenticação do UNIX ou pela autenticação LDAP, mas não pelos dois. Eu não posso adicionar atributos para os usuários no Active Directory, mas pode adicioná-los aos grupos de segurança (e realmente gostaria de exigir ainda mais que os usuários LDAP estejam em um grupo de segurança LDAP específico).

    

Answer 1

Obrigado por atualizar sua pergunta, que o conselho muitas vezes é levado ao caminho errado.

Seus requisitos como eu os compreendo:

• UID / GID de pesquisas para todos os usuários devem ser executados em arquivos locais.
• A autenticação para usuários específicos deve tentar primeiro o LDAP (Active Directory).

A versão curta é que sim, isso é possível, mas requer realmente entender como esses subsistemas funcionam e não confiar nos HOWTOs on-line. Vou me referir a uma resposta minha como cartilha. link

NSS é o sistema que realiza as pesquisas de UID e GID. Se você não modificar /etc/nsswitch.conf e disser para usar ldap ou sssd , suas chamadas de sistema dependerão dos arquivos locais. A maioria dos plug-ins do PAM para LDAP compartilha um arquivo de configuração com um plug-in do NSS para LDAP, mas isso não importará se o plug-in do NSS não estiver sendo usado pelo NSS.

Seu requisito para fazer isso apenas para usuários específicos é mais complicado. Configure o PAM para tentar pam_ldap.so (ou pam_krb5.so ou pam_winbind.so ... depende do que você está usando) como auth sufficient , imediatamente antes de auth required pam_unix.so . sufficient significa "bom o suficiente, pare aqui". required significa "se chegamos até aqui e este teste falhou, a autenticação falha".

Este é o método mais simples, mas há problemas:

1. Isso resultará em bloqueios de senha do AD se alguém estiver frequentemente se autenticando com uma senha local que não corresponda à senha do AD (ou seja, eles não serão autenticados com êxito no AD com frequência com outros sistemas).
2. Isso também não funcionaria para seus requisitos se você não quiser que senhas válidas do AD sejam consideradas para determinados usuários.

Deixe-me saber se você realmente precisa apenas autenticar no LDAP para uma lista específica de usuários. É definitivamente possível, mas aumentará a complexidade da configuração do PAM e eu já estou lançando um pouco de informação para você.

Expandindo a resposta conforme necessário:

Minha recomendação para um controle rigoroso sobre quem se autentica no AD é usar pam_access.so . Para que isso funcione, os módulos AD e Unix PAM devem ser adjacentes e nessa ordem. Coloque a seguinte linha na frente deles:

auth    [success=ignore default=1] pam_access.so accessfile=/etc/security/somefile.conf noaudit

success=ignore significa "se este teste for bem sucedido, ignore esta linha e prossiga normalmente". default=1 significa "em todos os outros casos, ignore a próxima linha". Você precisará criar somefile.conf e definir uma lista de usuários com permissão para usar a autenticação do AD. Verifique a página de manual para access.conf para mais detalhes. Você definirá uma lista de todos os usuários nesse arquivo ou criará um grupo local e testará a associação. Em todos os casos, o terceiro campo deve ser ALL . (por exemplo, + : whatever : ALL )

Seu requisito opcional (controle isso com um grupo de segurança do AD) pode ser implementado de duas maneiras:

1. Se o seu módulo PAM permitir que você especifique uma consulta LDAP que fará com que auth cheques sejam ignorados com base na associação ao grupo, use-a. Isso não é o mesmo que rejeitar o usuário via account se a senha for bem-sucedida!
2. Comprometimento em pesquisas de GID que atingem o diretório ativo. Isso significa que você teria passwd de pesquisas em ldap em /etc/nsswitch.conf , mas você adicionaria <%> a linha ldap a group . O objeto do grupo de segurança deve ser configurado para que possa ser reconhecido como um grupo Unix, aplicando a objectClass apropriada (por exemplo, posixGroup ) ou configurando o plug-in do NSS para reconhecê-lo como um. A menos que você tenha um histórico strong no LDAP, talvez queira transmitir isso.

Depois de configurar as coisas com sucesso até o ponto em que getent group está mostrando o grupo AD, você pode modificar seu arquivo de acesso para ter sucesso com base na participação desse grupo.