Substituição para NIS / YP

A empresa em que estou trabalhando está começando a substituir a atual estrutura NIS / YP desenvolvida localmente pelo LDAP.

Já temos o AD em casa para as coisas do Windows e gostaríamos de considerar o uso de um sistema AD. O pessoal do AD é bastante restritivo e não suporta modificações extensas.

É necessário que a substituição inclua o suporte, todos os recursos do conjunto NIS / YP incluem grupos de rede, restrições de login em servidores específicos para usuários ou grupos de usuários específicos, senhas consistentes entre o ambiente * nix e Windows, etc. Nosso ambiente é uma mistura de Linux (suse, RH, Debian), Sun, IBM, HP e MPRAS, além de um NETAPP. Portanto, tudo o que usamos deve ser totalmente inclusivo para todos os ambientes.

Analisamos a mesma situação, mas nossa administração deseja outras alternativas para comparar.

Que outras coisas devo observar e qual é a sua avaliação da alternativa?

obrigado

A Microsoft costumava ter algo chamado Services For Unix (ainda existe, mas com um nome diferente: agora é "Subsistema para Aplicativos Baseados em UNIX (SUA)") - Entre os recursos incluídos, estava um gateway AD-NIS que permite você cria um domínio NIS efetivamente escravizado no seu domínio do AD.
Este é provavelmente o caminho de menor resistência para você, já que seu ambiente unix é heterogêneo - Qualquer coisa que entenda o NIS entenderá o servidor MS NIS, porque, no que diz respeito aos seus sistemas unix, ainda é apenas um servidor NIS antigo.

Outra opção é pam_ldapd (ou pam_ldap + nss_ldap) - isso consulta diretamente os servidores AD e foge de algumas das limitações do NIS, mas não sei o quão bom o suporte do grupo de rede é e sobre isso (eu sei pam_ldap + nss_ldap não possui suporte a netgroup em funcionamento no FreeBSD).

você pode experimentar o freeipa ( http://freeipa.org ) do redhat pessoal. Ele serve para substituir nis / yp e oferece um ambiente kerberizado como um bônus. É claro que você pode simplesmente conectar os clientes com apenas pam_ldap, mas você perde a conexão única.

Você também pode sincronizar usuários com o AD, a propósito.

Como você já possui o AD em casa, recomendo considerar o freeipa / Redhat IDM configurado como um domínio confiável do diretório ativo. Além de ser gratuito, isso permite que você use todas as informações de usuários e grupos existentes no AD, enquanto define controles e políticas de acesso no ipa.

Você também tem o potencial kerberos & sso. O IPa nesta configuração apresenta grupos de anúncios como grupos de rede (como nis).

Ele vem com um bom guia da web e controle de acesso interno baseado em função (por exemplo, quem pode unir hosts ao domínio kerberos, quem pode gerenciar o sudo etc.).

Qualquer cliente deve poder se autenticar no ipa ou no AD.

QAS (qualquer versão) é uma solução ideal na minha opinião, exceto pelo custo, que pode ser insano. Também requer uma alteração de esquema para o AD, o que é bom, mas seus funcionários do AD podem não gostar disso.

As versões mais recentes do winbind são muito mais estáveis ​​que o 3.x, mas exigem que você tenha políticas de acesso (sudo, ssh) configuradas em cada host.

Eu não posso falar por centrificar.

Eu estive em ambientes que usavam o VAS (agora chamado outra coisa, da Quest) e o Centrify. Eu não mantive nenhum dos sistemas, eu era apenas um usuário. Então, não posso ajudá-lo a decidir, mas esses são outros nomes.

Pelo que vi, ambos funcionaram e ambos atenderam aos requisitos listados, embora sempre houvesse alguns soluços.

O Winbind funciona bem, especialmente com a opção RID. Use os servidores AD como os geradores de NTP para as caixas unix, isso facilita um pouco as coisas e funciona bem. Faça com que o kerberos trabalhe com o AD a seguir, é muito simples, verifique se o ntp está funcionando e se os clientes estão usando o anúncio para dns. A opção RID no winbind produzirá um uid previsível para usuários e gid para seus grupos. A configuração do samba / winbind permitirá que você escolha um shell que todos os usuários receberão; não tenho certeza se você pode configurar para que usuários individuais tenham shells diferentes; o usuário sempre pode iniciar o shell que quiser ao fazer login. As restrições de login podem ser mantidas através do sshd_config, restringindo com base em grupos. Você terá que começar com as máquinas mais antigas e a Netapp para ver se a versão do samba / winbind que você instala suporta a opção RID de back-end.