Senso comum sobre a autenticação do Active Directory para servidores Linux?

Question

Qual é o conhecimento comum em 2014 sobre autenticação / integração do Active Directory para servidores Linux e sistemas operacionais Windows modernos (focados no CentOS / RHEL)?

Ao longo dos anos, desde as minhas primeiras tentativas de integração em 2004, parece que as melhores práticas em torno disso mudaram. Eu não tenho certeza qual método atualmente tem o maior momento.

No campo, vi:

Winbind / Samba
Direto LDAP
Às vezes LDAP + Kerberos
Serviços do Microsoft Windows para Unix (SFU)
Microsoft Identity Management for Unix
NSLCD
SSSD
FreeIPA
Centrify
Powerbroker (< em> née do mesmo modo )

O Winbind sempre pareceu terrível e pouco confiável. As soluções comerciais como Centrify e Likewise sempre funcionaram, mas pareciam desnecessárias, já que essa capacidade é incorporada ao sistema operacional.

As últimas instalações que fiz tiveram o recurso de função Gerenciamento de identidades do Microsoft para Unix adicionado a um servidor Windows 2008 R2 e NSLCD no lado do Linux (para RHEL5). Isso funcionou até o RHEL6, onde a falta de manutenção no NSLCD e os problemas de gerenciamento de recursos de memória forçaram uma alteração no SSSD. A Red Hat também parecia apoiar a abordagem SSSD, o que está bem para o meu uso.

Estou trabalhando com uma nova instalação em que os controladores de domínio são sistemas Windows 2008 R2 Core e não tenho a capacidade de adicionar o recurso de gerenciamento do Identity Management for Unix. E me disseram que esse recurso está obsoleto se não houver mais presença no Windows Server 2012 R2 .

O benefício de ter essa função instalada é a presença dessa GUI, enquanto permite a administração fácil em uma etapa dos atributos do usuário.

Mas ...

The Server for Network Information Service (NIS) Tools option of Remote Server Administration Tools (RSAT) is deprecated. Use native LDAP, Samba Client, Kerberos, or non-Microsoft options.

Isso torna realmente difícil confiar se isso pode quebrar a compatibilidade. O cliente quer usar o Winbind, mas tudo que vejo do lado da Red Hat aponta para o uso do SSSD.

Qual é a abordagem correta?
Como você lida com isso no seu ambiente?

    

Answer 1

Em março de 2014, a Red Hat publicou uma arquitetura de referência para integrando o Red Hat Enterprise Server com o Active Directory . (Este material certamente deve ser atual e relevante.) Eu odeio postar isso como uma resposta, mas é realmente muito material para ser transferido para o campo de resposta.

Este documento (corrigido) está quente quando a imprensa parece se concentrar sobre os novos recursos do Red Hat Enterprise Linux (RHEL) 7. Ele foi publicado para a Cúpula na semana passada.

Se esse link ficar obsoleto, avise-nos e atualizarei a resposta adequadamente.

Eu pessoalmente usei o WinBind de maneira confiável para autenticação. Há uma falha de serviço muito pouco frequente que exige que alguém com raiz ou outra conta local entre e salte winbindd. Isso provavelmente poderia ser resolvido através de um monitoramento adequado, se você se dedicar a isso.

Vale a pena notar que o Centrify possui funcionalidades adicionais, embora isso possa ser fornecido por um gerenciamento de configuração separado. (Fantoche, etc.)

Editar 16/06/14:

Red Hat Enterprise Guia de Integração do Linux 7 para Windows

    

Answer 2

re: "The commercial solutions like Centrify and Likewise always worked, but seemed unnecessary, since this capability is baked into the OS."

Bem, eu acho que a maioria de nós tem ouvido há anos que o sistema operacional XYZ finalmente quebra o quebra-cabeça de integração do AD. IMHO o problema é que, para o fornecedor do sistema operacional, a integração do AD é um recurso de caixa de seleção, ou seja, eles precisam entregar algo que meio que funciona para obter essa caixa de seleção, e essa caixa de seleção normalmente só funciona em ...

1. sua plataforma de sistema operacional e
2. a versão atual dessa plataforma e
3. em relação a uma versão mais recente do Active Directory.

A realidade é que a maioria dos ambientes não é monolítica em termos de fornecedor do sistema operacional e versão do sistema operacional, e terá versões mais antigas do AD. É por isso que um fornecedor como o Centrify tem que suportar 450+ sabores de UNIX / Linux / Mac / etc. contra o Windows 2000 para o Windows 2012 R2, não apenas o RHEL 7 novamente, o Windows 2012 R2.

Além disso, você precisa levar em conta como o seu AD é implantado, assim como a integração AD do fornecedor do SO suporta Controladores de Domínio Somente Leitura (RODCs), relações de confiança unidirecionais, suporte a várias florestas, etc. tem espaço UID pré-existente (o que você irá), existem ferramentas de migração para migrar os UIDs para o AD. E o suporte AD do fornecedor do sistema operacional aborda a capacidade de mapear vários UIDs para um único AD em situações em que seu espaço UID não é plano. E o que aconteceu ... bem, você entendeu.

Depois, há a questão do suporte ...

O ponto é que a integração AD pode parecer fácil conceitualmente e pode ser "gratuita" com o SO mais recente de um fornecedor e provavelmente funcionará se você tiver apenas uma versão de um SO de um fornecedor e tiver um AD vanilla que seja a versão mais recente. e você tem um contrato de suporte premium com o fornecedor do sistema operacional, que fará o possível para resolver os problemas que surgirem. Caso contrário, você pode querer considerar uma solução especializada de terceiros.

    

Answer 3

The Server for Network Information Service (NIS) Tools option of Remote Server Administration Tools (RSAT) is deprecated.

Isso não é surpresa para mim - o NIS é uma evidência de que a Sun nos odiava e queria que fôssemos infelizes.

Use native LDAP, Samba Client, Kerberos, or non-Microsoft options.

Este é um bom conselho. Dadas as escolhas eu diria "Use LDAP nativo (sobre SSL, por favor)" - há muitas opções disponíveis para isso, as duas que eu estou mais familiarizado com ser pam_ldap + nss_ldap (da PADL), ou o conjunto nss-pam-ldapd (que se originou como uma bifurcação e viu desenvolvimento e aprimoramentos contínuos).

Como você está perguntando sobre o RedHat especificamente, é importante notar que RedHat fornece outras alternativas usando SSSD.
Se o seu ambiente é todo-RedHat (ou apenas tem um grande número de sistemas RedHat) olhando para o oficialmente apoiado "RedHat Way of Doing Things" certamente valeria a pena.

Como não tenho experiência com o RedHat / SSSD, estou apenas passando pelos documentos, mas parece ser bem robusto e bem projetado.

    

Answer 4

Tem que comentar sobre isso:

It is worth noting that Centrify does have additional functionality, though this can be provided by separate configuration management. (Puppet, etc.)

Como alguém que trabalha com o Centrify, não sabe de onde vem esse comentário. Veja este e você pode ver que há um monte de recursos que você não usa obter com uma ferramenta de configuração mgmt ala Puppet. Por exemplo, suporte para o mapeamento de vários UIDs para uma única conta do AD (Zones), suporte para relações de confiança completas no domínio do Active Directory (que a solução Red Hat documenta na página 3 e que ele não suporta), etc.

Mas voltemos a este guia da Red Hat. É ótimo que a Red Hat esteja publicando isso, as opções são boas. Observe que ele oferece ao cliente 10 opções para fazer a integração básica do AD. A maioria das opções são variações do Winbind, e a página 15 lista as vantagens e desvantagens de cada uma, e há um monte de etapas manuais necessárias para cada uma delas (com as correspondentes desvantagens / falta de funcionalidade acima). A vantagem do Centrify Express é que, pelos outros comentadores acima, é:

1. é simples de instalar sem todas as etapas manuais e ...
2. é grátis e ...
O
3. não se limita ao Red Hat V7, o que é importante, pois a questão tem a ver com o Linux, não apenas com uma variante - o Centrify suporta mais de 300 versões do * nix e ...
4. suporta todas as variantes do Windows AD, não apenas do Windows 2008. Eles publicaram uma comparação entre Centrify e Winbind aqui , mas não é de código aberto.

No final, tudo se resume a você querer rolar sozinho ou usar uma solução comercial. Realmente é uma questão onde você e como você gasta o seu tempo.

    

Answer 5

Dos métodos sugeridos, deixe-me dar uma lista de prós e contras:

Direto para o Kerberos / LDAP

Prós: funciona muito bem quando configurado corretamente. Raramente quebra, resiliente, irá sobreviver falhas de rede. Nenhuma alteração precisa no AD, nenhuma alteração de esquema, nenhum acesso de Administrador necessário ao AD. Grátis.

Contras: relativamente difícil de configurar. Vários arquivos precisam ser alterados. Não funcionará se o servidor de autenticação (Kerberos / LDAP) não estiver disponível.

Winbind

Prós: fácil de configurar. Funcionalidade básica do sudo. Grátis.

Contras: suporte intensivo. Não é resiliente à rede. Se houver um problema de rede, as máquinas Linux poderão ser excluídas do AD, exigindo a reconexão do servidor, uma tarefa de suporte. Acesso à conta de administrador do AD necessário. Poderia fazer alterações no esquema no AD.

Centrifique / Da mesma forma, etc.

Prós: relativamente fácil de configurar.

Contras: Altera a funcionalidade do sudo para proprietária, mais difícil de suportar. Custo de licença por servidor. Precisa de habilidades adicionais para gerenciar.

SSSD

Prós: um arquivo de configuração, fácil de configurar. Funciona com todos os métodos de autenticação presentes e futuros. Escalável, cresce com o sistema. Funcionará no modo desconectado. Rede resiliente. Não há necessidade de fazer qualquer alteração no esquema do AD. Não há necessidade de credenciais de administrador do AD. Gratuito, suportado.

Contras: não possui serviços de vitória, como atualizações automáticas de DNS. Precisa configurar compartilhamentos CIFS.

Resumo

Olhando para as vantagens e desvantagens, o SSSD é o vencedor claro. Se for um novo sistema, não há razão para usar outra coisa senão SSSD. É um integrador que trabalha com todos os métodos de autenticação presentes e pode crescer com o sistema porque novos métodos podem ser adicionados quando disponíveis. Ele usa métodos nativos do Linux e é muito mais confiável e rápido. Se o armazenamento em cache estiver ativado, os sistemas funcionarão mesmo em sistemas completamente desconectados com total falha de rede.

O Winbind pode ser usado para sistemas existentes se houver muito trabalho envolvido para mudar.

A Centrify teve problemas com a integração, o que pode custar caro. A maioria dos bugs é corrigida na nova versão, mas ainda há alguns que causam dores de cabeça.

Trabalhei com todos esses métodos e o SSSD é o vencedor claro. Mesmo para sistemas mais antigos, o ROI para converter de Winbind para SSSD é muito alto. A menos que haja uma razão específica para não usar o SSSD, sempre use o SSSD.