Gerenciamento de usuários descentralizado

Question

Eu preciso de algum usermanagement para um serverfarm de +/- 30 servidores linux. Normalmente, eu pensaria em algo como o LDAP, mas não queremos depender de um servidor global para o qual precisamos autenticar, em caso de tempo de inatividade ou conexões interrompidas.

Então eu estava pensando em escrever alguns scripts que sincronizam / etc / passwd e / etc / shadow e verifica se existem homedirectories. Incluindo a possibilidade de excluir alguns usuários em alguns dos servidores.

Mas ... eu não poderia imaginar que sou a única pessoa no mundo que precisaria de algo assim. Então, alguém conhece um projeto opensource que faz uma coisa dessas?

    

Answer 1

Eu não vi uma solução de código aberto, mas nós fizemos a nossa antes. É relativamente simples ter root run rsync e sincronizar /etc/passwd , /etc/shadow e diretórios iniciais contendo chaves SSH autorizadas.

Uma coisa a ter em mente é que a cópia "mestre" de /etc/passwd e /etc/shadow precisa ter os detalhes de todos os usuários em todos os sistemas. Isso significa que se você tiver uma máquina com o MySQL e outra com o Apache, o arquivo passwd / shadow precisará conter o usuário mysql e o usuário www-data . Isso leva a que haja mais entradas em passwd / shadow em algumas máquinas do que é necessário.

Outra observação: é melhor fazer isso o mais cedo possível na implementação / configuração, pois você pode acabar lidando com a colisão de UID ao criar o "mestre". Se você implementar isso em sistemas que já estão em execução, será necessário descobrir qual usuário tem qual UID e alterar as permissões de diretório / arquivo em cada sistema de acordo.

    

Answer 2

Eu ainda digo LDAP, mesmo com suas advertências. O ponto único de falha de autenticação centralizada é um problema conhecido há alguns anos, e é por isso que o Windows livrou-se do modelo PDC / BDC do WinNT e optou por um modelo distribuído de vários mestres a partir do Active Directory. O eDirectory da Novell (um servidor LDAP muito bom, entre outras coisas) já faz multi-master há mais de 15 anos. Ambos podem funcionar bem separados do restante da rede de autenticação, por meio de links WAN lentos e funcionar apesar do processo usual de interrupção / reinicialização / recriação que marca toda a TI. Com a exceção de tempos de inatividade prolongados (dia ou mais), esse é um problema amplamente resolvido.

Apenas não tanto no espaço de código aberto, que eu já vi. O OpenLDAP tem replicação entre vários servidores LDAP, o que lhe dá sua tolerância a falhas.

Ramificando um pouco, se você tiver um ambiente do Active Directory para trabalhar com o Samba vem com maneiras de trabalhar com o AD que fará o processamento de identidades multi-mestre. Se um DC estiver inoperante, ele falará com outros. Se você não tem medo do Samba 4 ainda em desenvolvimento, você pode até configurar um ambiente de AD completamente baseado no Linux, e usar o winbind em seus servidores clientes para lidar com a autenticação distribuída.

    

Answer 3

A solução mais simples seria ter um sistema mestre e um cron job em execução nos nós individuais para rsync os arquivos passwd, shadow e group regularmente. Parece um hack sujo e desagradável.

Em um sentido mais amplo, você pode usar o boneco como uma ferramenta de gerenciamento de configuração abrangente. Isso inclui contas de usuários. Com efeito, você define todos os atributos do usuário e membros do grupo globalmente. Em seguida, em uma base de grupo de máquinas ou por máquina, você define os grupos, ou usuários individuais, que têm acesso ao sistema. Como a autenticação e a autorização estão ocorrendo localmente, mesmo que o seu puppetmaster esteja inativo, os usuários ainda poderão fazer o login. Você só perderia a propagação de alterações.

Como o fantoche gerencia apenas os arquivos e serviços que você define explicitamente, facilita o gerenciamento centralizado de alguns aspectos, enquanto gerencia localmente outros.

    

Answer 4

É por isso que o Active Directory requer (bem, quase de qualquer maneira) vários servidores. Então, quando um deles morre, você não está ferrado.

Se você tem uma base de usuários de qualquer tamanho, não quer depender do gerenciamento descentralizado, mesmo que seja por meio de algo como fantoche. Moves Adds and Changes (MACs) não será divertido. Em absoluto. Além disso, sem autenticação centralizada, você precisará gerenciar contas locais, contas samba, contas htaccess ... onde você poderia autenticar de forma centralizada todos de uma vez.

Por favor, reconsidere a autenticação centralizada para sua própria sanidade.

    

Answer 5

Será que algo como funciona ? Aparentemente eles usam o MySQL para escalar uma instalação do OpenLDAP e replicá-la.

Acho que o Kerberos também pode ser configurado para ser distribuído. Este é um artigo antigo que discute um pouco sobre isso.

Não sei se você tem algum sistema Windows AD em sua rede, mas, se você, você pode configurar módulos para autenticar contra isso .

    

Answer 6

Eu ainda digo que o LDAP é a melhor escolha. Insanamente confiável, muito fácil de manter. Eu tenho executado pares LDAP master / slave em produção há vários anos sem uma falha. No meu trabalho anterior, eles forneceram autenticação para 20 a 30 servidores e centenas de estações de trabalho. Pelo que sei, eles nunca falharam como resultado de uma falha. Quando eu deliberadamente falhai (reboot / upgrade / etc) ninguém notou.

Dito isso, há uma solução que faz quase exatamente o que você descreve, mas com a vantagem de ser gerenciada centralmente: NIS . Ele distribui passwd, hosts, grupos, etc. através de um protocolo cliente-servidor, mas é capaz de continuar a funcionar se o servidor desaparecer. É um pouco complexo, mas é suportado por todos os sistemas operacionais que eu possa imaginar.

    

Answer 7

O LDAP é excelente, mas adiciona alguma complexidade com a qual você pode não estar preparado para lidar. Além disso, você terá que criar ferramentas e gerenciamento de configuração nos servidores para trabalhar com o LDAP. Embora os módulos PAM (Pluggable Authentication Modules, módulos de autenticação conectáveis) no Linux ajudem bastante em algumas de suas necessidades, eles podem não atender a todos eles.

Também posso sugerir o uso de algo como puppet ( link ). Embora eu não tenha usado muito, pode ser uma solução total para você em vez de LDAP ou como meio de adicionar ferramentas e endereçar casos que o LDAP não faz.

    

Answer 8

embora não seja legal, você pode replicar o banco de dados do ldap (ou parte dele) nos clientes ldap (na verdade, os servidores)

a fraqueza disso é que o banco de dados é corrompido quando os clientes ldap são corrompidos, a vantagem é que você terá muitas réplicas, tornando seus dados incrivelmente seguros e se a conexão cair entre os bancos de dados master e slave, você pode continuar usando a réplica

    

Answer 9

Vou entrar em contato com o resto e sugerir LDAP. Se você realmente quer arquivos passwd locais, considere gerá-los a partir do LDAP. Você poderia gerá-los em algum lugar central e depois distribuí-los (fantoche, rsync, etc.), ou você poderia ter cada cliente gerar o seu próprio. Se o servidor LDAP estiver indisponível, o arquivo passwd local ainda estará lá para ser usado. Ter o servidor LDAP lá e manter as informações permite que você vá em frente e use ou crie as ferramentas necessárias para provisionamento e gerenciamento de usuários, portanto, se você decidir confiar em sua rede / configurar servidores redundantes, terá uma migração muito simples. caminho.