Saggezza comune sull'autenticazione di Active Directory per i server Linux?

Qual è la saggezza comune nel 2014 sull'autenticazione / integrazione di Active Directory per server Linux e moderni sistemi operativi Windows Server (incentrati su CentOS / RHEL)?

Nel corso degli anni dai miei primi tentativi di integrazione nel 2004, sembra che le migliori pratiche al riguardo siano cambiate. Non sono del tutto sicuro di quale metodo abbia attualmente più slancio.

Nel campo, ho visto:

Winbind / Samba
Straight-up LDAP
volte LDAP + Kerberos
Microsoft Windows Services for Unix (SFU)
di Microsoft Identity Management per Unix
NSLCD
SSSD
FreeIPA
Centrify
PowerBroker ( nata Allo stesso modo )

Winbind sembrava sempre terribile e inaffidabile. Le soluzioni commerciali come Centrify e Allo stesso modo hanno sempre funzionato, ma sembravano non necessarie, poiché questa funzionalità è integrata nel sistema operativo.

Le ultime installazioni che ho fatto hanno avuto la funzione di ruolo Microsoft Identity Management per Unix aggiunta a un server Windows 2008 R2 e NSLCD sul lato Linux (per RHEL5). Questo ha funzionato fino a RHEL6, dove la mancanza di manutenzione su NSLCD e problemi di gestione delle risorse di memoria hanno costretto a cambiare SSSD. Anche Red Hat sembrava supportare l'approccio SSSD, quindi è andato bene per il mio uso.

Sto lavorando con una nuova installazione in cui i controller di dominio sono sistemi Core di Windows 2008 R2 e non hanno la possibilità di aggiungere la funzione ruolo Identity Management for Unix. E mi è stato detto che questa funzionalità è obsoleta non è più presente in Windows Server 2012 R2 .

Il vantaggio di avere questo ruolo installato è la presenza di questa GUI, mentre consente una facile amministrazione in un solo passaggio degli attributi dell'utente.

Ma...

L'opzione Server for Network Information Service (NIS) di Remote Server Administration Tools (RSAT) è obsoleta. Utilizza le opzioni LDAP native, Samba Client, Kerberos o non Microsoft.

Ciò rende davvero difficile fare affidamento su se potrebbe interrompere la compatibilità futura. Il cliente desidera utilizzare Winbind, ma tutto ciò che vedo dal lato Red Hat punta all'uso di SSSD.

Qual è l'approccio giusto?
Come gestisci questo nel tuo ambiente?

Nel marzo 2014, Red Hat ha pubblicato un'architettura di riferimento per l' integrazione di Red Hat Enterprise Server con Active Directory . (Questo materiale dovrebbe certamente essere attuale e pertinente.) Odio pubblicare questo come risposta, ma è davvero troppo materiale da trasferire nel campo della risposta.

Questo documento (corretto) è caldo sulla stampa e sembra focalizzarsi sulle nuove funzionalità di Red Hat Enterprise Linux (RHEL) 7. È stato pubblicato per il Summit la scorsa settimana.

Se questo link dovesse diventare obsoleto, per favore fatemi sapere e aggiornerò la risposta di conseguenza.

Personalmente ho usato WinBind in modo abbastanza affidabile per l'autenticazione. C'è un errore di servizio molto raro che richiede a qualcuno con account root o altro di accedere e far rimbalzare winbindd. Questo potrebbe probabilmente essere affrontato attraverso un adeguato monitoraggio se ti interessa impegnarti.

Vale la pena notare che Centrify ha funzionalità aggiuntive, sebbene ciò possa essere fornito da una gestione della configurazione separata. (Burattino, ecc.)

Modifica il 16/06/14:

Red Hat Enterprise Linux 7 Guida all'integrazione di Windows

ri: "Le soluzioni commerciali come Centrify e Allo stesso modo hanno sempre funzionato, ma sembravano non necessarie, poiché questa funzionalità è integrata nel sistema operativo."

Bene, penso che la maggior parte di noi abbia sentito per anni che il sistema operativo XYZ ha finalmente risolto il puzzle dell'integrazione AD. IMHO il problema è che per il fornitore del sistema operativo, l'integrazione AD è una funzione di casella di controllo, cioè devono fornire qualcosa che in qualche modo funziona per ottenere quella casella di controllo, e quella casella di controllo funziona solo su ...

1. la loro piattaforma del sistema operativo e
2. la versione attuale di quella piattaforma e
3. contro una versione più recente di Active Directory.

La realtà è che la maggior parte degli ambienti non sono monolitici in termini di fornitore del sistema operativo e versione del sistema operativo e avranno versioni precedenti di AD. Ecco perché un fornitore come Centrify deve supportare oltre 450 versioni di UNIX / Linux / Mac / ecc. contro Windows 2000 a Windows 2012 R2, non solo RHEL 7 di nuovo Windows 2012 R2.

Inoltre, è necessario considerare in che modo viene distribuito l'AD, quindi l'integrazione AD del fornitore del sistema operativo supporta i controller di dominio di sola lettura (RODC), i trust unidirezionali, fornisce supporto multi-foresta, ecc. E se si dispone di pre spazio UID esistente (che vuoi), ci sono strumenti di migrazione per migrare gli UID in AD. E il supporto AD del fornitore del sistema operativo affronta la possibilità di mappare più UID su un singolo annuncio in situazioni in cui lo spazio UID non è piatto. E che dire ... beh, hai capito.

Poi c'è la questione del supporto ...

Il punto è che l'integrazione AD può sembrare concettualmente semplice e può essere "gratuita" con l'ultimo sistema operativo di un fornitore e probabilmente può funzionare se si dispone di una sola versione di un sistema operativo di un fornitore e si dispone di un annuncio vanilla che è l'ultima versione e si ha un contratto di supporto premium con il fornitore del sistema operativo che farà del proprio meglio per risolvere eventuali problemi che si presentano. Altrimenti potresti prendere in considerazione una soluzione di terze parti specializzata.

L'opzione Server for Network Information Service (NIS) di Remote Server Administration Tools (RSAT) è obsoleta.

Questa non è una sorpresa per me: la NIS è la prova che Sun ci odiava e voleva che fossimo infelici.

Utilizza le opzioni LDAP native, Samba Client, Kerberos o non Microsoft.

Questo è un buon consiglio Date le scelte che direi "Usa LDAP nativo (su SSL, per favore)" - ci sono molte opzioni disponibili per questo, le due con cui ho più familiarità sono pam_ldap + nss_ldap (da PADL) o il combinato nss-pam- ldapd (che è nato come fork e ha visto continui sviluppi e miglioramenti).

Dal momento che stai chiedendo di RedHat in particolare, vale la pena notare che RedHat ti offre altre alternative usando SSSD.
Se il tuo ambiente è tutto-RedHat (o ha solo un gran numero di sistemi RedHat), esaminando il "Modo di fare le cose" supportato ufficialmente, varrebbe sicuramente la pena.

Dato che non ho esperienza con RedHat / SSSD, vado solo dai documenti, ma sembra essere abbastanza robusto e ben progettato.

Dei metodi suggeriti, lascia che ti dia un elenco di vantaggi / svantaggi:

Verso l'alto Kerberos / LDAP

Pro: funziona alla grande se configurato correttamente. Rotture rare, resilienti, sopravvivranno a problemi di rete. Non sono necessarie modifiche in AD, nessuna modifica dello schema, nessun accesso da parte dell'amministratore ad AD. Gratuito.

Contro: relativamente difficile da configurare. È necessario modificare più file. Non funzionerà se il server di autenticazione (Kerberos / LDAP) non è disponibile.

winbind

Pro: facile da configurare. Funzionalità di base sudo. Gratuito.

Contro: supporto intensivo. Non resiliente alla rete. Se c'è un problema di rete, le macchine Linux potrebbero essere eliminate dall'AD, richiedendo di nuovo la registrazione del server, un'attività di supporto. È richiesto l'accesso all'account amministratore di AD. Potrebbe essere necessario apportare modifiche allo schema in AD.

Centrifugare / Allo stesso modo ecc.

Pro: relativamente facile da configurare.

Contro: cambia la funzionalità sudo in proprietaria, più difficile da supportare. Costo della licenza per server. Hai bisogno di ulteriori competenze da gestire.

SSSD

Pro: un file di configurazione, facile da configurare. Funziona con tutti i metodi di autenticazione presenti e futuri. Scalabile, cresce con il sistema. Funzionerà in modalità disconnessa. Resistente alla rete. Non è necessario apportare alcuna modifica allo schema AD. Non sono necessarie credenziali di amministratore AD. Gratuito, supportato.

Contro: non ha servizi vincenti come gli aggiornamenti automatici di DNS. È necessario configurare le condivisioni CIFS.

Sommario

Guardando vantaggi e svantaggi, SSSD è il chiaro vincitore. Se si tratta di un nuovo sistema, non vi è alcun motivo per utilizzare qualcosa di diverso da SSSD. È un integratore che funziona con tutti i metodi di autenticazione presenti e può crescere con il sistema perché è possibile aggiungere nuovi metodi quando disponibili. Utilizza metodi Linux nativi ed è molto più affidabile e veloce. Se la memorizzazione nella cache è attivata, i sistemi funzioneranno anche in sistemi completamente disconnessi con errore di rete completo.

Winbind può essere utilizzato per sistemi esistenti se c'è troppo lavoro da modificare.

Centrify ha avuto problemi di integrazione che potrebbero essere costosi. La maggior parte dei bug sono stati corretti nella nuova versione, ma ce ne sono ancora alcuni che causano mal di testa.

Ho lavorato con tutti questi metodi e SSSD è il chiaro vincitore. Anche per i sistemi più vecchi, il ROI per la conversione da Winbind a SSSD è molto alto. A meno che non vi sia un motivo specifico per non utilizzare SSSD, utilizzare sempre SSSD.

Devi commentare questo:

Vale la pena notare che Centrify ha funzionalità aggiuntive, sebbene ciò possa essere fornito da una gestione della configurazione separata. (Burattino, ecc.)

Come qualcuno che lavora con Centrify non è sicuro da dove provenga quel commento. Guarda questo e puoi vedere che c'è un carico di funzioni che non ottieni con uno strumento di configurazione mgmt ala Puppet. Ad esempio, supporto per la mappatura di più UID su un singolo account AD (Zone), supporto per trust di dominio di Active Directory completi (che la soluzione Red Hat documenta a pagina 3 che non supporta), ecc.

Ma torniamo a questa guida di Red Hat. È fantastico che Red Hat lo stia pubblicando, le opzioni sono buone. Nota che offre al cliente 10 opzioni per eseguire l'integrazione di base AD. La maggior parte delle opzioni sono varianti di Winbind e, a pagina 15, elenca i vantaggi e gli svantaggi di ciascuno e vi è una serie di passaggi manuali richiesti per ciascuno (con corrispondenti svantaggi / mancanza di funzionalità per quanto sopra). Il vantaggio di Centrify Express è che per gli altri commentatori sopra è:

1. è semplice da installare senza tutti i passaggi manuali e ...
2. è gratuito e ...
3. non è limitato a Red Hat V7, che è importante poiché la domanda riguardava Linux, non solo una variante: Centrify supporta oltre 300 versioni di * nix e ...
4. supporta tutte le varianti di Windows AD, non solo Windows 2008. Hanno pubblicato un confronto tra Centrify e Winbind qui , ma non è open source.

Alla fine si riduce per farti rotolare da solo o andare con una soluzione commerciale. Davvero una questione di dove e come passi il tuo tempo.