Come unire un sistema Linux a un dominio Active Directory

Active Directory (AD) di Microsoft è il servizio di directory di riferimento per molte organizzazioni. Se tu e il tuo team siete responsabili di un ambiente misto Windows e Linux, probabilmente vorrete centralizzare l'autenticazione per entrambe le piattaforme. Tratterò come aggiungere computer Linux a un dominio di Active Directory.

Active Directory e la necessità di una gestione centralizzata degli accessi

Active Directory di Microsoft, più popolarmente noto come AD, detiene da molti anni la parte del leone nel mercato della gestione degli accessi aziendali. Viene utilizzato da istituzioni e individui in tutto il mondo per controllare centralmente l'accesso alle risorse appartenenti all'organizzazione. Ti dà la possibilità di gestire utenti, password, risorse come i computer e determinare chi ha accesso a cosa. Per alcuni di voi che stanno leggendo questo articolo, specialmente quelli che lavorano in grandi istituzioni, avete già interagito con AD. Di solito, l'interazione utilizza un set di credenziali di accesso per accedere a qualsiasi workstation dell'organizzazione. Questa è solo la punta di un grande iceberg.

Immagina una raccolta di 40 sistemi informatici e 70 utenti in un'azienda. Alcuni dipendenti fanno i turni mentre altri lavorano con orario regolare. Alcuni hanno accesso alla stampa; altri no. Il modo tradizionale di lavorare consiste nel creare account utente locali su ogni computer a cui un utente deve accedere. Immagina il carico di lavoro del team di supporto degli utenti finali. Quando un utente cambia la sua password per qualsiasi motivo, quell'utente deve cambiare la password su tutti i computer a cui aveva accesso in precedenza, per mantenere le cose sincronizzate. In men che non si dica, ci sarà il caos. Ora, immagina che due membri dello staff si dimettano. Non ho bisogno di dirti il ​​lavoro monotono che deve essere ripetuto ogni volta che c'è un cambiamento nel personale o in qualsiasi postazione di lavoro. Per i team IT, questo è un incubo. Il tempo che potrebbe essere utilizzato per attività innovative è ora speso per reinventare la ruota. Non ho nemmeno parlato della gestione dell'accesso alle stampanti.

È qui che prospera un servizio di directory come Active Directory. Può letteralmente essere un vero toccasana. Con Active Directory, ogni utente viene creato in modo univoco come oggetto in un database centrale, con un unico set di credenziali. Ogni sistema informatico viene creato anche come oggetto. Automaticamente, ogni utente può accedere a ogni workstation con lo stesso set di credenziali. Eventuali modifiche all'account che devono essere apportate vengono apportate una volta al database centrale. I membri del personale possono accedere alle stampanti utilizzando lo stesso set di credenziali. Il meccanismo di autenticazione delle stampanti può essere accoppiato con AD per raggiungere questo obiettivo. Utenti felici, team IT felice.

Utilizzando gruppi e unità organizzative, l'accesso a varie risorse può essere personalizzato e mantenuto. Diventa ancora meglio. Questa directory può memorizzare numeri di telefono del personale, indirizzi e-mail e può essere estesa per memorizzare altre informazioni. E se qualcuno si dimette? Nessun problema. Disabilita semplicemente l'account dell'utente. L'accesso di quella persona a tutte le risorse viene immediatamente annullato. Più grande è l'organizzazione, maggiore è la necessità di una gestione centralizzata. Risparmia tempo; salva le emozioni.

Al suo interno, un servizio di directory è solo un modo organizzato per elencare tutte le risorse in un'organizzazione facilitando al contempo un facile accesso a tali risorse. Fondamentalmente, AD è una sorta di database distribuito, a cui si accede in remoto tramite il Lightweight Directory Access Protocol (LDAP). LDAP è un protocollo aperto per l'accesso remoto ai servizi di directory su un supporto orientato alla connessione come TCP/IP. AD non è l'unico servizio di directory basato sullo standard x.500 o accessibile tramite LDAP. Altri servizi di directory includono OpenLDAP e FreeIPA. Tuttavia, AD è un servizio maturo basato su Windows che viene incorporato con i sistemi Windows Server. In altre parole, sarà il vincitore automatico quando la tua organizzazione ha molti sistemi Windows. Questo è uno dei motivi della sua ubiquità. I servizi di directory come FreeIPA sono basati su Linux e forniscono un servizio eccellente per una stalla Linux. Quando la gomma colpisce la strada, la scelta si riduce a quale delle due puoi impostare rapidamente, dato il tuo ambiente attuale e il set di abilità della tua squadra.

[ Potrebbe piacerti anche: Interoperabilità tra Windows e Linux:uno sguardo a Samba ]

Ma cosa succede quando scegli AD e hai alcuni server CentOS e non vuoi mantenere un set separato di credenziali per i tuoi utenti Linux? Quel sovraccarico è del tutto evitabile. Quello che devi fare è unire i server Linux al dominio AD, come faresti con un server Windows.

Se questo è ciò che devi fare, continua a leggere per scoprire come farlo. È possibile unire un sistema Windows a un dominio FreeIPA, ma questo esula dallo scopo di questo articolo.

Prerequisiti

Questo articolo presuppone che tu abbia almeno un'esperienza di livello introduttivo con Active Directory, in particolare sulla gestione degli account utente e computer. A parte questo, devono essere soddisfatti i seguenti ovvi requisiti:

• Un account in AD che dispone dei privilegi necessari per unire un sistema al dominio.
• Un server Linux (per questa dimostrazione è stato utilizzato un server CentOS 7).
• Un controller di dominio.
• Assicurati che il tuo server Linux sappia come trovare il controller di dominio tramite DNS.

Per rendere questo articolo più semplice per tutti, ecco un elenco di dettagli chiave. Questo è il modo in cui è impostato il lab che ho usato per questa scrittura, quindi dovresti modificare di conseguenza.

• Nome di dominio AD:Hope.net
• Account utente per l'adesione al dominio:fkorea (Fullname - Fiifi Korea)
• Nome host del server Linux:centy2

Pacchetti da installare

Per questa configurazione, il pacchetto essenziale da installare è realmd . A parte realmd , ci sono una miriade di pacchetti che devono essere installati per farlo funzionare.

# yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

Realmd fornisce un modo semplificato per scoprire e interagire con i domini di Active Directory. Impiega sssd per eseguire le ricerche effettive richieste per l'autenticazione remota e altri lavori pesanti di interazione con il dominio. Per ragioni di brevità, non mi soffermerò sugli altri pacchetti nell'elenco.

Tuttavia, per chi è interessato ai dettagli, una rapida ricerca su Google dovrebbe essere di grande aiuto.

Realmd (interazione con il dominio)

Ora che tutti i pacchetti sono stati installati, la prima cosa da fare è unire il sistema CentOS al dominio Active Directory. Usiamo il realm domanda per quello. Il realm il client viene installato contemporaneamente a realmd . Viene utilizzato per unire, rimuovere, controllare l'accesso e svolgere molte altre attività. Ecco la sintassi prevista per un semplice accesso a un dominio:

realm join --user=[domain user account] [domain name]

Lo spazio tra l'account utente e l'account di dominio non è un errore di battitura. Inserendo i dettagli corrispondenti, otteniamo il seguente comando:

# realm join --user=fkorea hope.net

Fornisci la password quando viene visualizzata la richiesta e attendi la fine del processo.

Non lasciarti ingannare dalla breve assenza di output. Ci sono una serie di operazioni che vanno avanti come parte del processo. Puoi virare su -v passare per un output più dettagliato. Tuttavia, il modo migliore per verificare se il computer è ora un membro del dominio è eseguire l'realm list comando. Il comando tenta di visualizzare lo stato corrente del server rispetto al dominio. È un modo rapido e sporco per sapere quali gruppi o utenti possono accedere al server.

Dai un'occhiata al suo output:

È anche abbastanza banale posizionare l'oggetto computer AD appena creato in una specifica unità organizzativa (UO) sin dall'inizio. Lo lascerò per ulteriori letture, ma, come consiglio, puoi consultare la pagina man. Usando il realm client, puoi concedere o revocare l'accesso a utenti e gruppi di dominio. Un'analisi approfondita dell'utilizzo di realmd in modo più fine è sufficiente fare un altro articolo. Tuttavia, non sarò fuori luogo nel selezionare alcuni parametri alla tua attenzione, vale a dire il software client e il software server. A questo punto dovresti capire perché abbiamo dovuto installare così tanti pacchetti.

Per abbandonare del tutto il dominio, hai bisogno di due parole:realm leave

Ulteriore configurazione

Quindi ora che il server Linux fa parte del dominio AD, gli utenti del dominio possono accedere al server con le loro solite credenziali. Abbiamo finito, vero? Sbagliato. "Qual è il problema?" Ti sento dire.

Bene, per cominciare, questa è la configurazione barebone per farti funzionare. Ma l'esperienza è goffa, per non dire altro. Abbiamo bisogno di configurare ulteriormente il servizio per dargli una vera sensazione di AD. Dovrebbe essere proprio come accedere a una workstation Windows 10 aggiunta a un dominio.

In secondo luogo, c'è il grande elefante nella stanza per gli amministratori di sistema chiamato Aggiornamenti DNS dinamici (DynDNS). Se non è impostato correttamente, creiamo un sovraccarico aggiuntivo dovendo mantenere manualmente i record DNS. Per un ambiente che fa molto affidamento sul DNS, questo potrebbe essere un problema. Per i sistemi Windows, l'unione di un sistema al dominio significa che due voci vengono gestite e mantenute automaticamente sul server DNS. Quando gli indirizzi IP cambiano, la modifica si riflette automaticamente nel DNS. Ciò significa che è possibile modificare gli IP dei sistemi senza sostenere il costo della manutenzione manuale. Questo avrà senso solo per le persone che già sfruttano il DNS nei loro ambienti. A parte i notevoli guadagni di produttività dell'automazione, aiuta a far funzionare allo stesso modo gli ambienti Windows e Linux.

Il terzo problema è lo scavenging DNS. In un dominio Active Directory, il DNS viene generalmente fornito dai controller di dominio. Ogni sistema unito al dominio ha una voce DNS automatica con un indirizzo IP corrispondente. Questo è super conveniente. Automaticamente, a un intervallo specificato, i record DNS non aggiornati vengono eliminati per prevenire i pacchetti indirizzati in modo errato e anche per prendersi cura degli oggetti del computer eliminati. Questo è noto come scavenging e non è attivato per impostazione predefinita in AD. Tuttavia, se è acceso, è necessario configurarlo. In genere, l'intervallo di scavenging è di sette giorni. Se, trascorso tale periodo, il record non è stato aggiornato, viene eliminato, a meno che non si tratti di un record statico. Per i sistemi Windows, la funzionalità Aggiornamenti dinamici viene impostata automaticamente. Tuttavia, con i server Linux, è necessario apportare alcune modifiche. Senza farlo, dopo un po' avremo servizi che si interromperanno perché i loro record vengono eliminati dal DNS e nessuno sa come raggiungere i loro componenti.

Ora che conosciamo alcuni dei potenziali problemi che dobbiamo affrontare, diamo un'occhiata ad alcune delle cose che possiamo modificare per offrire un'esperienza più fluida all'utente finale e all'amministratore di sistema.

SSSD (accesso facilitato e aggiornamenti dinamici)

sssd su un sistema Linux è responsabile per consentire al sistema di accedere ai servizi di autenticazione da un'origine remota come Active Directory. In altre parole, è l'interfaccia principale tra il servizio di directory e il modulo che richiede i servizi di autenticazione, realmd . Il suo file di configurazione principale si trova in /etc/sssd/sssd.conf . Questo è infatti il ​​file di configurazione principale che andremo a modificare.

Diamo un'occhiata al suo contenuto prima della configurazione. Una volta entrato a far parte del dominio, questo viene immediatamente modificato per contenere le informazioni minime richieste per un accesso riuscito. Il mio file era simile a questo:

Per risolvere tutti e tre i problemi che ho menzionato in precedenza, modifica il tuo file in modo che assomigli a quello qui sotto:

La maggior parte delle opzioni sono autoesplicative e puoi modificare la tua di conseguenza mentre spiegheremo ciò che rappresentano alcune delle opzioni chiave. Maggiori informazioni su tutte le opzioni possono essere ottenute controllando la pagina man. Penso che sia scritto bene. Basta digitare man 5 sssd.conf alla riga di comando. Puoi anche visualizzare la pagina man di sssd_ad per ulteriori informazioni.

Innanzitutto, il file di configurazione è diviso in due sezioni. La sezione globale, in [sssd] e la sezione delle opzioni specifiche del dominio, [dominio/[nome dominio]] .

La sezione globale contiene opzioni che influiscono sul comportamento generale di sssd , come le informazioni sulla versione e i servizi correlati. Un parametro chiave in questa sezione è mostrato di seguito:

• suffisso_dominio_predefinito - Impostalo sul nome di dominio se non vuoi dover digitare il nome completo dell'account utente durante l'accesso. Invece di dover digitare [email protected] sempre, puoi semplicemente digitare fkorea e la password. Questo aiuta molto quando hai un nome di dominio lungo.

La sezione specifica del dominio contiene parametri specifici del dominio a cui ti sei unito. I parametri chiave sono:

• provider_accesso - Consente di selezionare un provider ottimizzato e utilizzato per interagire con i server AD a fini di autenticazione. Dovrebbe essere impostato su ad . Altri valori che possono essere utilizzati qui sono ldap e ipa , supponendo che utilizzi quei servizi di directory.
• id_provider - Consente di selezionare un provider ottimizzato e utilizzato per interagire con i server AD a fini di identificazione. Dovrebbe essere impostato su ad .
• nome_host_annuncio - Questo dovrebbe essere il nome host completo del server. Dovrebbe essere impostato se il nome host del sistema è diverso dal nome di dominio completo. Se questo non è impostato e il sssd non ha accesso al nome host completo, gli aggiornamenti dinamici non riusciranno.
• dominio_ad - Dovrebbe essere il nome di dominio completo (hope.net in questo caso).
• credenziali_cache - Ciò consente agli utenti AD di accedere quando il controller di dominio è offline. Quando è impostato su true , le credenziali vengono memorizzate nella cache per un periodo tale che l'autenticazione non fallisce quando il back-end è offline. Anche il periodo di archiviazione è configurabile.
• fallback_homedir - Questo ti aiuta a impostare una home directory per gli utenti AD che non hanno un attributo di home directory in AD. Questo è diverso da override_home parametro che funziona quando una directory home è impostata in AD per gli utenti.
• dyndns_update - Ciò abilita gli aggiornamenti DNS dinamici e accetta sia true o falso come valore. Quando gli aggiornamenti dinamici sono abilitati, gli aggiornamenti si verificano principalmente in tre condizioni:
  • Quando il server Linux si riavvia.
  • Quando il provider è online.
  • Quando scade l'intervallo di aggiornamento.
• dyndns_refresh_interval - Questo valore è espresso in secondi con un minimo pratico di 60 secondi. Accetta valori interi e ha un valore predefinito di 24 ore (86400). In questo esempio, lo impostiamo su 12 ore. Se nient'altro attiva un aggiornamento, un aggiornamento viene eseguito regolarmente tra.
• dyndns_update_ptr - Un valore booleano che specifica se il record PTR associato deve essere aggiornato in ogni ciclo di aggiornamento. I record PTR vengono utilizzati per le ricerche inverse e, a meno che non vi sia una buona ragione, questo dovrebbe essere impostato su true .
• dyndns_auth - Specifica se gli aggiornamenti dinamici devono essere eseguiti in modo sicuro o meno. L'impostazione dipende dalla modalità accettata da AD. Se AD è impostato su Accetta solo aggiornamenti protetti , questo valore deve essere impostato su GSS-TSIG . In caso contrario, e non ti interessano i vantaggi in termini di sicurezza degli aggiornamenti dinamici sicuri (nonostante il forte avviso in AD), questo valore può essere impostato su nessuno .

Una volta completata la configurazione, riavvia sssd per applicare le impostazioni immediatamente.

# systemctl restart sssd

A questo punto siamo a posto. Ora possiamo accedere come faremmo su una workstation o un server Windows.

Visudo (concessione dei privilegi di amministratore)

Gli utenti a cui è concesso l'accesso hanno accesso non privilegiato al server Linux. A tutti gli effetti, tutti gli account di Active Directory sono ora accessibili al sistema Linux, allo stesso modo in cui gli account locali creati in modo nativo sono accessibili al sistema. Ora puoi eseguire le normali attività di amministratore di sistema per aggiungerli ai gruppi, renderli proprietari delle risorse e configurare altre impostazioni necessarie. Se l'utente prova un'attività che richiede sudo accesso, viene presentato l'errore familiare. Come si può vedere nel riquadro, il nostro utente non è nei sudoers file.

In questa luce, possiamo modificare i sudoers file direttamente per concedere loro i privilegi di superutente. Questo non è un articolo sulla concessione dei privilegi di superutente, ma possiamo usare il visudo strumento per interagire in sicurezza con i sudoers file.

In alternativa, avremmo semplicemente aggiunto l'utente alla wheel gruppo. Il punto è che l'account utente è ora disponibile per essere utilizzato dal sistema.

[ Rete fuori controllo? Dai un'occhiata all'automazione della rete per tutti, un libro gratuito di Red Hat. ] 

Concludi

Provalo nella tua organizzazione o ambiente di laboratorio. È ovvio che ho appena scalfito la superficie su questo argomento, ma questo ti porterà abbastanza lontano nel processo. Consulta la rispettiva documentazione se desideri esplorare le opzioni non trattate in questo articolo.

L'unione di un sistema Linux a un dominio Active Directory ti consente di ottenere il meglio da entrambi i mondi. Il processo è molto semplice e può essere eseguito tramite script utilizzando Bash o automatizzato utilizzando Ansible, soprattutto durante la configurazione iniziale del sistema. Se stai ancora gestendo un gruppo di più di cinque sistemi senza un servizio di directory e una buona ragione, fatti un favore e fallo configurare. Puoi ringraziarmi più tardi.