Lidando com centenas de servidores RHEL, como podemos manter contas raiz locais e contas de usuário de rede? Existe uma solução do tipo diretório ativo que os gerencia de um local central?
Lidando com centenas de servidores RHEL, como podemos manter contas raiz locais e contas de usuário de rede? Existe uma solução do tipo diretório ativo que os gerencia de um local central?
Respostas:
Um componente central do Active Directory é o LDAP, disponível no Linux na forma de OpenLDAP e 389DS (e alguns outros). Além disso, o outro componente principal Kerberos está disponível na forma de MIT Kerberos e Heimdal . Finalmente, você pode até conectar suas máquinas ao AD.
sudoersregras (ou ambas).
Você pode tentar com o fantoche para gerenciar o usuário:
Por que usar o Puppet para gerenciar contas de usuário? (e não NIS, LDAP, etc.)
Um dos benefícios do gerenciamento de contas de usuário no fantoche é o fato de ser descentralizado. Cada conta de usuário é apenas uma conta de usuário normal no servidor gerenciado. Não há nada de especial nas contas de usuário que o fantoche cria além do fato de terem sido criadas por fantoche e não por um administrador humano. O bom disso é que, se o host principal morre, não perdemos a autenticação. O que significa que nosso servidor puppetmaster (ou servidor NIS / LDAP) não precisa ter nenhum requisito especial de tempo de atividade. Se ocorrer uma emergência, podemos nos concentrar em colocar nossos servidores de produção em funcionamento, e em colocar o mestre de bonecos “conforme necessário”. A desvantagem disso é que o fantoche não é necessariamente projetado para gerenciar contas de usuário de login "normais" (em oposição às contas do sistema). A maior maneira que isso acontece é que, embora você possa definir a senha no fantoche, o fantoche monitora continuamente as configurações do sistema (boas) e, se perceber que a senha foi alterada, a redefinirá. (incorreto) Não quero monitorar senhas de usuários em nossa rede, portanto, é necessário que haja uma maneira de definir uma senha e que o fantoche pare de monitorar essa senha. Felizmente, depois de descobrir o truque, isso é realmente muito fácil. Mas primeiro, vamos tirar algumas definições do caminho.
Como o SvenW menciona, existem 389DS e Kerberos. Desde o RHEL 6.2, a Red Hat incluiu o IPA na distribuição (e, portanto, também está no CentOS). Este é um conjunto completo de gerenciamento de identidades que incorpora 389DS e Kerberos, com controle baseado em políticas sobre autenticação e autorização e, opcionalmente, DNS. Pode até ser configurado para sincronização unidirecional ou bidirecional com o Active Directory.
O IPA requer praticamente SSSD nos hosts RHEL, mas funciona sem ele. Até testei a conexão do Solaris 10 ao IPA (funciona, mas um pouco complicado). O IPA é bastante simples de configurar para hosts RHEL.
Isso é baseado no projeto FreeIPA .
Para suas contas de usuário de rede, o OpenLDAP como o SvW mencionado.
Você também deve consultar "Sistemas de gerenciamento de configuração" para gerenciar suas contas locais e tudo mais em seus servidores. Dê uma olhada no CFEngine, Bcfg2, Puppet e Chef. Se você estiver usando a AWS, eles têm uma coisa do Chefy com o OpsWorks.
Se você realmente precisa gerenciar mais de 100 servidores, possui 10 Sysadmins ou usa o software Configuration Management.
Esta pode ser uma resposta óbvia, mas 'use o diretório ativo'. Você precisa modificar um pouco nosso esquema do AD, para incluir campos específicos do unix, mas depois disso, você terá um único diretório de todas as suas contas de usuário que funcionam em várias plataformas.
Talvez seja menos útil se você é uma loja exclusiva do Unix - mas eu realmente não vi muitas delas. Mas o AD é, na verdade, uma boa combinação dos principais elementos do LDAP e do Kerberos. Acho isso meio irônico, na verdade.
Mas o que você obtém 'de graça' são as contas de plataforma cruzada e a integração do Kerberos para que você possa exportar NFSv4 aplicando ACLs 'reconhecidas por CIFS' e montagens NFS krb5i / p, com autenticação forte do usuário.