Antes que você ria de mim e diga: “Se você quiser o Active Directory, use o Windows” ou me diga para usar o Google, me escute.
Minha empresa depende muito do AD. Não, estamos casados com isso neste momento e, como empresa da Fortune 10, isso não vai mudar. No entanto, temos muitos sistemas *nix em nosso ambiente (principalmente RHEL e SLES) e ainda não encontrei um bom mecanismo para integração com o Active Directory como fonte de identidade. No mínimo, preciso de algo para fornecer o seguinte:
- Autenticação via credenciais AD (permitindo a entrada de um usuário)
- Autorização uma vez autenticada (concedendo ao usuário acesso a áreas do sistema)
- Auditoria (ser capaz de vincular as ações do usuário às suas credenciais do AD)
- Suporte para grupos AD (não apenas LDAP simples e necessidade de adicionar/remover usuários individuais em sistemas)
- Não é uma fonte de identidade duplicada/espelhada baseada na confiança do AD (não preciso de dois sistemas enormes)
As principais soluções que encontrei são as seguintes:
- Centralizar
- PowerBroker Open (PBIS Open, anteriormente Similar-Open)
- SSSD+SELinux
Centralizar. . . é simplesmente feio. Nunca fui um fã de verdade. Além disso, para as necessidades da minha empresa, não podemos usar o Centrify-Express, portanto não é gratuito e não há licença ilimitada. No entanto, é a melhor solução que encontramos e estou desesperado para encontrar outra coisa.
PBIS Open é o que estou inclinado. É o que o VMware usa no backend do vShield e funciona muito bem. Requer apenas alguns comandos para ser configurado, oferece suporte a grupos AD e não há sistema secundário de gerenciamento de identidade - ele se comunica diretamente com o AD. A única razão para eu não seguir esse caminho é que gosto de soluções nativas, e se houver uma maneira melhor de fazer isso que já esteja incluída nas distros modernas, sou totalmente a favor.
SSSD + SELinux parecia ótimo. É difícil de configurar, mas é flexível, nativo e compatível com a maioria das distros modernas. A única coisa que falta (pelo que entendi) é suporte para grupos AD. Muitos artigos sugerem aproveitar o FreeIPA ou algo semelhante para adicionar essa funcionalidade, mas após uma leitura mais aprofundada, isso viola o requisito 5 e basicamente cria um serviço de identidade intermediário. Não estou interessado em basicamente duplicar o AD ou estabelecer confiança em um serviço de identidade secundário.
Outras opções de kludge que usei incluem o uso do Puppet (que usamos) para enviar arquivos /etc/password,shadow,group para endpoints, mas isso requer desenvolvimento, é incrivelmente indireto e pude ver algo indo mal. Uma opção melhor seria adicionar SSSD+SELinux à ideia do Puppet. Embora simplificasse o desastre, ainda é um desastre.
O que estou perdendo, o que você está usando e qual é a "nova novidade" que não considerei para resolver a dor de cabeça da integração do Linux AD?
Responder1
Suas soluções aqui são FreeIPA ou Centrify/PowerBroker. O FreeIPA faz parte de sua assinatura RHEL padrão, portanto já há algumas economias.
O FreeIPA pode ser executado em um modo onde todos os usuários e grupos podem vir do Active Directory. Você só manteria o mapeamento desses usuários e grupos para ambientes específicos do POSIX no FreeIPA, como regras SUDO, chaves SSH públicas, definições de controle de acesso baseadas em host, atribuições de contexto do SE Linux e assim por diante. Para fazer isso, você precisaria mapear alguns de seus usuários/grupos AD para alguns grupos no FreeIPA, mas isso não é uma duplicação das informações, é uma alteração com as partes que não são específicas do AD.
A maneira como o FreeIPA implementa a compatibilidade com o Active Directory é apresentando-se como uma espécie de floresta compatível com o Active Directory. É suficiente para permitir que os recursos do FreeIPA sejam consumidos pelos usuários do AD por meio de confiança entre florestas, mas não o suficiente para permitir que os usuários do FreeIPA acessem sistemas Windows do outro lado da confiança. Você parece estar interessado na primeira parte, então tudo bem.
Com o FreeIPA 4.1, que já faz parte do RHEL 7.1 beta (espero que o RHEL 7.1 seja lançado 'em breve'), temos um mecanismo poderoso para manter as substituições para usuários e grupos AD no FreeIPA e o SSSD é capaz de descobrir todos eles em granularidade por servidor.
Responder2
Eu realmente gostaria de ouvir o que você quer dizer com "grupos reais de AD" quando fala sobre SSSD. As versões mais recentes do SSSD não exigem que os grupos tenham atributos POSIX e principalmente leiam as associações de grupos de TokenGroups se o provedor AD for usado.
Além disso, no RHEL-7.1 (upstream 1.12+), o SSSD ganhou a capacidade de fazer verificações de controle de acesso usando políticas de GPO.
Sinta-se à vontade para entrar e escrever para a lista de usuários sssd se tiver uma pergunta específica.
Responder3
A oferta Redhat é bem abordada aqui:
Conhecimento comum sobre autenticação do Active Directory para servidores Linux?
Em minhas instalações recentes, isso foi feito por meio de filtros de grupo SSSD (integrados) e ldap ou sssd.conf.
O que exatamente seus usuários Linux precisamfazernos sistemas?
Responder4
e quanto ao winbind + samba + kerberos?
- Autenticação via credenciais AD (permitindo a entrada de um usuário)
verificado
- Autorização uma vez autenticada (concedendo ao usuário acesso a áreas do sistema)
verificado
- Auditoria (ser capaz de vincular as ações do usuário às suas credenciais do AD)
/var/log/seguro? verificado
- Suporte para grupos AD (não apenas LDAP simples e necessidade de adicionar/remover usuários individuais em sistemas)
permite grupos de anúncios ou usuários de anúncios em grupos locais, verificado
- Não é uma fonte de identidade duplicada/espelhada baseada na confiança do AD (não preciso de dois sistemas enormes)
freeipa não é necessário, verificado