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

Soluzione 1:

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 pubblicarlo come risposta, ma è davvero troppo materiale da trasferire nel campo della risposta.

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

Se questo link diventa obsoleto, per favore fatemelo sapere e aggiornerò la risposta di conseguenza.

Personalmente ho utilizzato WinBind in modo abbastanza affidabile per l'autenticazione. C'è un errore di servizio molto raro che richiede a qualcuno con root o altro account locale di entrare e rimbalzare winbindd. Questo potrebbe probabilmente essere affrontato tramite un monitoraggio adeguato 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 16/6/14:

Guida all'integrazione di Red Hat Enterprise Linux 7 Windows

Soluzione 2:

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

Beh, penso che la maggior parte di noi abbia sentito per anni che il sistema operativo XYZ risolve finalmente il puzzle dell'integrazione AD. IMHO il problema è che per il fornitore del sistema operativo, l'integrazione AD è una funzionalità della casella di controllo, ovvero devono fornire qualcosa che in qualche modo funzioni per ottenere quella casella di controllo, e quella casella di controllo in genere funziona solo su...

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

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

Inoltre, è necessario tenere conto della modalità di distribuzione dell'AD, così come l'integrazione AD del fornitore del sistema operativo supporta controller di dominio di sola lettura (RODC), trust unidirezionali, fornisce supporto multi-foresta, ecc. spazio UID esistente (cosa che farai), 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 AD 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 di AD può sembrare facile concettualmente 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 AD vaniglia che è l'ultima versione e si dispone un contratto di supporto premium con il fornitore del sistema operativo che farà del proprio meglio per risolvere eventuali problemi che si presenteranno. Altrimenti potresti prendere in considerazione una soluzione specializzata di terze parti.

Soluzione 3:

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

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

Usa LDAP nativo, client Samba, Kerberos o opzioni non Microsoft.

Questo è un buon consiglio. Date le scelte, 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 la combinazione nss-pam- ldapd (che ha avuto origine come fork e ha subito continui sviluppi e miglioramenti).

Dato che stai chiedendo specificamente di RedHat, vale la pena notare che RedHat ti offre altre alternative usando SSSD.
Se il tuo ambiente è interamente RedHat (o ha solo un gran numero di sistemi RedHat), esaminare il "RedHat Way of Doing Things" ufficialmente supportato varrebbe sicuramente la pena.

Dato che non ho esperienza con RedHat/SSSD, mi limito a seguire i documenti, ma sembra essere abbastanza robusto e ben progettato.

Soluzione 4:

Dei metodi suggeriti, lascia che ti dia un elenco di pro/contro:

Direttamente Kerberos/LDAP

Pro:funziona alla grande se configurato correttamente. Raramente si rompe, resiliente, sopravviverà ai problemi di rete. Non sono necessarie modifiche in AD, nessuna modifica dello schema, nessun accesso amministratore necessario ad AD. Gratuito.

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

Vincolo

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

Contro:Supporto intensivo. Rete non resiliente. Se si verifica un problema di rete, le macchine Linux potrebbero essere eliminate dall'AD richiedendo la nuova registrazione del server, un'attività di supporto. È richiesto l'accesso all'account amministratore di AD. Potrebbe essere necessario apportare modifiche allo schema in AD.

Centrificare/Likewise ecc.

Pro:relativamente facile da configurare.

Contro:modifica la funzionalità sudo in proprietaria, più difficile da supportare. Costo della licenza per server. Hai bisogno di competenze aggiuntive 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. Rete resiliente. Non è necessario apportare alcuna modifica allo schema AD. Non sono necessarie le credenziali di amministratore AD. Gratuito, supportato.

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

Riepilogo

Guardando vantaggi e svantaggi, SSSD è il chiaro vincitore. Se si tratta di un nuovo sistema, non c'è motivo di 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 errori di rete completi.

Winbind può essere utilizzato per i sistemi esistenti se è necessario modificare troppo lavoro.

Centrify ha avuto problemi con l'integrazione che potrebbero diventare costosi. La maggior parte dei bug è stata corretta nella nuova versione, ma ce ne sono ancora alcuni che causano grattacapi.

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

Soluzione 5:

Devo 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 sono sicuro da dove provenga quel commento. Guarda questo e puoi vedere che c'è un carico di funzionalità che non ottieni con uno strumento di config mgmt ala Puppet. Ad esempio, supporto per la mappatura di più UID su un singolo account AD (Zone), supporto per trust di dominio 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 pubblichi, le opzioni sono buone. Nota che offre al cliente 10 opzioni per eseguire l'integrazione AD di base. La maggior parte delle opzioni sono variazioni di Winbind, e pagina 15 elenca i vantaggi e gli svantaggi di ognuna, e c'è una serie di passaggi manuali richiesti per ognuna (con i corrispondenti svantaggi/mancanza di funzionalità come 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, il che è importante in quanto la domanda ha a che fare con Linux, non solo con una variante:Centrify supporta oltre 300 versioni di *nix e...
4. supporta tutte le varianti di Windows AD, non solo Windows 2008. Hanno pubblicato qui un confronto tra Centrify e Winbind, ma non è open source.

Alla fine si riduce a se vuoi farlo da solo o andare con una soluzione commerciale. Davvero una questione di dove e come passi il tuo tempo.