Gestendo centinaia di server RHEL, come possiamo mantenere account root locali e account utente di rete? Esiste una soluzione di tipo di directory attiva che li gestisce da una posizione centrale?
Gestendo centinaia di server RHEL, come possiamo mantenere account root locali e account utente di rete? Esiste una soluzione di tipo di directory attiva che li gestisce da una posizione centrale?
Risposte:
Un componente centrale di Active Directory è LDAP, che è disponibile su Linux sotto forma di OpenLDAP e 389DS (e alcuni altri). Inoltre, l'altro componente principale Kerberos è disponibile sotto forma di MIT Kerberos e Heimdal . Infine, puoi persino connettere le tue macchine ad AD.
sudoersregole (o entrambe).
Puoi provare con Puppet per la gestione degli utenti:
Perché usare Puppet per gestire gli account utente? (e non NIS, LDAP, ecc.)
Uno dei vantaggi della gestione degli account utente nelle marionette è il fatto che è decentralizzato. Ogni account utente è solo un normale account utente sul server gestito. Non c'è nulla di speciale negli account utente creati da Puppet oltre al fatto che sono stati creati da Puppet e non da un amministratore umano. La cosa bella di questo è che se l'host principale muore, non perdiamo l'autenticazione. Ciò significa che il nostro server puppetmaster (o server NIS / LDAP) non ha bisogno di particolari requisiti di uptime. Se si verifica un'emergenza, possiamo concentrarci su come rendere operativi i nostri server di produzione e concentrarci su come rendere il burattinaio "secondo necessità". L'aspetto negativo di questo è che il pupazzo non è necessariamente progettato per gestire account utente di accesso "normali" (al contrario degli account di sistema). Il modo più grande che si presenta è che, sebbene sia possibile impostare la password in Puppet, Puppet monitora continuamente le impostazioni di sistema (buona) e se si accorge che la password è stata modificata, la reimposterà. (cattivo) Non voglio monitorare le password degli utenti sulla nostra rete, quindi è necessario un modo per impostare una password e fare in modo che il burattino smetta di monitorare questa password. Fortunatamente, una volta che hai capito il trucco, questo è davvero molto semplice. Ma prima, togliiamo alcune definizioni.
Come menziona SvenW, ci sono 389DS e Kerberos. Da RHEL 6.2, Red Hat ha incluso IPA nella distribuzione (e quindi anche in CentOS). Questa è una suite completa di gestione delle identità che incorpora 389DS e Kerberos, con controllo basato su criteri su autenticazione e autorizzazione e, facoltativamente, DNS. Può anche essere configurato per la sincronizzazione unidirezionale o bidirezionale con Active Directory.
L'IPA richiede praticamente SSSD su host RHEL ma funziona senza di essa. Ho anche provato a collegare Solaris 10 a IPA (funziona, ma un po 'complicato). L'IPA è piuttosto semplice da configurare per gli host RHEL.
Questo si basa sul progetto FreeIPA .
Per i tuoi account utente di rete OpenLDAP come SvW menzionato.
Dovresti anche consultare "Sistemi di gestione della configurazione" per gestire i tuoi account locali e tutto il resto sui tuoi server. Dai un'occhiata a CFEngine, Bcfg2, Puppet e Chef. Se stai usando AWS, hanno un aspetto da Chef con OpsWorks.
Se hai davvero bisogno di gestire oltre 100 server, hai 10 amministratori di sistema o usi il software di gestione della configurazione.
Questa potrebbe essere una risposta ovvia, ma "usa active directory". Devi modificare un po 'il nostro schema AD, per includere campi specifici unix, ma una volta fatto, hai una singola directory di tutti i tuoi account utente che funziona su più piattaforme.
Forse meno utile se sei un negozio solo Unix - ma in realtà non ne ho visti molti. Ma AD è in realtà un discreto mesh degli elementi chiave di LDAP e Kerberos. Lo trovo davvero ironico.
Ma ciò che otterrai "gratuitamente" sono gli account multipiattaforma e l'integrazione Kerberos in modo da poter eseguire le esportazioni NFSv4 applicando ACL "CIFS riconosciuti" e montaggi NFS krb5i / p, con autenticazione utente (er) avanzata.