Substituição por NIS / YP

Question

A empresa para a qual estou trabalhando está embarcando na substituição da estrutura atual do NIS / YP localmente desenvolvida pelo LDAP.

Já temos o AD interno para o material do Windows e gostaríamos de considerar o uso de um sistema AD. As pessoas do AD são bastante restritivas e não suportariam modificações extensas.

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

Nós analisamos a Likewise, mas nossa gerência quer outras alternativas para comparar.

Que outras coisas eu deveria estar olhando e qual é sua avaliação da alternativa?

Obrigado

    

Answer 1

A Microsoft costumava ter algo chamado Services For Unix (ainda está por aí, mas com um nome diferente: agora é "Subsistema para Aplicativos Baseados em UNIX (SUA)") - Entre os recursos incluídos estava um AD-to-NIS gateway que permite que você crie um domínio NIS que seja efetivamente aceito em 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 ele ainda é apenas um servidor NIS simples.

Outra opção é pam_ldapd (ou pam_ldap + nss_ldap) - Isso consultaria seus servidores AD diretamente & fica longe de algumas das limitações do NIS, mas eu não sei o quão bom é o suporte a netgroup e tal é sobre estes (eu sei pam_ldap + nss_ldap não tem suporte a netgroup de trabalho no FreeBSD).

    

Answer 2

você pode experimentar o freeipa ( link ) do pessoal do redhat. Destina-se a substituir nis / yp e dá-lhe um ambiente kerberized como um bônus. É claro que você pode simplesmente conectar clientes apenas com pam_ldap, mas você perde então o single sign-on.

Você também pode sincronizar usuários com o AD.

    

Answer 3

Dado que você já tem 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 todos os usuários existentes & agrupar informações no AD, ao definir controles de acesso e políticas no ipa.

Você também obtém kerberos & potencial sso. Ipa nesta configuração apresenta grupos de anúncios como netgroups (como nis).

Ele vem com um bom web gui e controle de acesso baseado em função interna (por exemplo, quem pode juntar hosts ao reino kerberos, quem pode gerenciar o sudo, etc).

Qualquer cliente deve poder autenticar-se contra o ipa ou o AD.

O QAS (qualquer versão) é uma solução ideal na minha opinião, exceto pelo custo, que pode ser insano. Ele também requer uma mudança de esquema para o AD, que por si só é bom, mas seus caras 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 requerem que você tenha políticas de acesso (sudo, ssh) configuradas em cada host.

Eu não posso falar por centrificar.

    

Answer 4

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

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

    

Answer 5

O Winbind funciona bem, especialmente com a opção RID. Use os servidores AD como o NTP maters para as caixas unix, torna as coisas um pouco mais fáceis e funciona bem. Obtenha o kerberos trabalhando com o AD em seguida, é muito simples, apenas certifique-se de que o ntp esteja funcionando e os clientes estejam usando o anúncio para o dns. A opção RID no winbind produzirá um uid previsível para usuários e gid para seus grupos. A configuração samba / winbind permitirá escolher um shell que todos os usuários obterão, não tenho certeza se você pode configurar para que os usuários individuais tenham shells diferentes, o usuário sempre pode iniciar o shell que quiser quando fizer o 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 com o Netapp para ver se a versão do samba / winbind que você instala suporta a opção RID de backend.