Installare xRDP su RHEL 8.x, join a dominio Active Directory e connessione xRDP utilizzando gli utenti Active Directory
Vedremo come installare su Red Hat Enterprise Linux 8.x il software xRDP per potersi collegare in modalità remota utilizzando Connessione Desktop Remoto di Windows, effettuare la join a Dominio Active Directory Windows e accedere al sistema RHEL utilizzando gli utenti AD mediante xRDP.
Da questo momento, tutti i comandi che verranno indicati in questo articolo, saranno eseguiti come utente root.
Per prima cosa, è necessario aggiornare il nostro sistema, aprite un terminale e digitate:
# dnf update
Quindi installiamo xRDP sulla nostra RHEL 8. Per l’installazione abbiamo bisogno di abilitare i repository EPEL, apriamo un terminale come root e digitiamo:
# dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
Avremo una schermata come questa:
Quindi procediamo accettando quanto proposto:
Ora che abbiamo abilitato i repository EPEL, possiamo procedere con l’installazione di quanto richiesto per poter connetterci utilizzando Connessione Desktop Remoto di Windows, installiamo i pacchetti con il seguente comando:
# dnf install -y tigervnc-server xrdp
Terminata l’installazione, andremo ad avviare il servizio con il comando:
# systemctl start xrdp
xRDP dovrebbe essere ora in ascolto sulla porta 3389, possiamo verificarlo utilizzando il comando netstat:
# netstat -antup | grep xrdp
Che produrrà un output come questo:
Per default, il servizio xRDP non si avvierà automaticamente al boot, andremo quindi ad abilitarlo utilizzando il comando:
# systemctl enable xrdp
Ancora un passaggio e poi sarà possibile collegarsi in modalità Desktop Remoto alla nostra RHEL, dobbiamo abilitare le porte nel firewall, quindi digitiamo i seguenti comandi, uno dopo l’altro in quest’ordine:
# firewall-cmd --permanent --add-port=3389/tcp
# firewall-cmd --reload
In questo modo abbiamo abilitato la porta 3389 sul protocollo TCP, ora è possibile collegarsi in Desktop Remoto utilizzando gli utenti locali:
Ora che abbiamo la possibilità di accedere in modalità Desktop Remoto con i nostri utenti locali, effettuiamo la join a Dominio Active Directory e, successivamente, configuriamo l’accesso in modalità Desktop Remoto anche per gli utenti AD.
Premessa
A partire dal suo rilascio (nel 1991) Linux prevedeva esclusivamente autenticazioni locali o verso sistemi NIS, successivamente sono state sviluppate integrazioni con i sistemi di directory che erano disponibili all’epoca e, successivamente (indicativamente ad inizio millennio), verso i sistemi Windows.
A seguito delle evoluzioni di entrambi i sistemi, le integrazioni divennero via via più strette, diventando possibile integrare completamente l’autenticazione di Linux in Active Directory.
Parlando di integrazione verso AD, generalmente vengono considerate le risorse che sono messe a disposizione dai sistemi; in questo tipo di scenario il dominio AD viene utilizzato come sorgente di autenticazione a cui i sistemi, Linux e Windows, fanno riferimento per consentire l’accesso alle rispettive risorse.
Le funzioni di autenticazione fanno parte di uno scenario più ampio di integrazione, l’evoluzione di queste possibilità (all’inizio molto rigide), ha portato allo sviluppo di moduli di autenticazione aperti, quali PAM (Pluggable Authentication Module), in questo modo, non solo il sistema operativo ma qualunque servizio che sia in grado di interfacciarsi con questi moduli, avrà la possibilità di autenticare i propri utenti verso AD.
Provider di Autenticazione
Linux è un Universo che comprende variegate distribuzioni e versioni, comprendere in un unico articolo tutte le differenze di implementazione che contraddistinguono le varie release sarebbe impossibile, motivo per cui mi soffermerò sulla distribuzione Red Hat 8.x.
Winbind e SSSD
Come premesso, nel corso degli anni le soluzioni di autenticazione sono cambiate, tra queste, nativamente su Linux sono disponibili Winbind e SSSD, vediamo le differenze tra le due.
Winbind
Winbind è un ambiente integrato all’interno di Samba e viene utilizzato come provider di autenticazione, su Linux è disponibile al sistema come Modulo PAM, quindi, può essere utilizzato da diversi servizi per poter effettuare autenticazioni verso Active Directory.
L’evoluzione del modulo Winbind ha seguito l’evolversi di Windows integrandosi dapprima con NTLM e, successivamente, con AD a mezzo di Kerberos.
È bene precisare che Winbind è stata (ed è) la soluzione privilegiata fino alla versione 6.8 del sistema operativo Red Hat.
SSSD
A partire dalla versione 7 del sistema operativo, Winbind è stato “dismesso” in favore di SSSD (System Security Services Daemon) diventandone il modello di riferimento.
SSSD nasce come derivazione del progetto FreeIPA e può sostituire Winbind nei processi di autenticazione verso sistemi centralizzati quali AD, LDAP e altri.
È un servizio che nasce a sé stante, a differenza di Winbind che è compreso all’interno di Samba. SSSD presenta le seguenti differenze rispetto a Winbind:
- consente più connettori verso sorgenti diverse: AD, LDAP, FreeIPA etc.
- mantiene in cache le credenziali utilizzate in modo da ridurre il traffico di autenticazione e permette l’accesso ai sistemi anche se il Domain Controller non è disponibile
- consente un debug più semplice rispetto a Winbind
- non supporta NTLM come protocollo di autenticazione
- non supporta Trust di Active Directory di tipo Cross Forest, in questo caso si rende necessario l’utilizzo di sistemi IDM per l’autenticazione
Fatte queste premesse, procediamo ora alla preparazione del nostro sistema RHEL per l’autenticazione verso AD, io ho scelto di utilizzare SSSD per i vantaggi esposti sopra a scapito del supporto per NTLM (che non mi interessa, dovendo fare join in un Domini AD su Windows Server 2016/2019) e del Trust di AD, anche questo non mi interessa in questo scenario.
Iniziamo con l’installazione dei pacchetti necessari:
- Oddjob
- Oddjob-mkhomedir
- SSSD
- Samba-common-tools
- Adcli
Per installare i pacchetti procediamo con il comando dnf eseguito come utente root:
# dnf install oddjob oddjob-mkhomedir sssd samba-common-tools adcli
Alcuni dei precedenti pacchetti potrebbero essere già presenti sul vostro sistema RHEL, verranno ignorati automaticamente, procedete accettando l’installazione dei pacchetti mancanti e delle relative dipendenze fino al completamento dell’installazione.
Ora il vostro sistema è pronto per effettuare la join a dominio AD, vediamo come!
Utilizzeremo il comando realm (che, una volta terminata l’installazione di tutti i precedenti pacchetti, sarà disponibile sul nostro sistema).
Realm è un tool da riga di comando che permette di configurare l’enrollment di un sistema all’interno di un REALM Kerberos come è Active Directory, se il sistema Linux è configurato correttamente, con questo comando si può effettuare il discovery in modo da ottenere le informazioni preliminari utili alla successiva integrazione; questa funziona utilizza il DNS di Active Directory per fornire e/o recuperare le informazioni relative a Kerberos, di conseguenza sarà necessario configurare la propria connessione di rete all’utilizzo dei DNS di AD (come avviene ed è necessario, per la join di sistemi Windows in AD), una volta configurati correttamente i DNS, lanciamo il seguente comando:
# realm discover -v test.local (sostituite test.local con il nome del vostro dominio AD)
Se tutto è stato configurato a dovere, avremo un output simile a questo:
Come si può vedere, viene effettuata una ricerca DNS su _ldap.tcp.test.local in riferimento al dominio DNS di default specificato nella configurazione di rete del sistema Linux.
Ora che siamo sicuri che il Dominio Active Directory sia raggiungibile, ovvero che il DNS sia correttamente configurato per fornire le informazioni, procediamo con il passo successivo, effettuare la join al dominio.
Utilizzeremo sempre il comando realm:
# realm join -v TEST.LOCAL
Avremo un output iniziale simile a questo:
Dove ci verrà chiesto di inserire le credenziali per l’utente Administrator, una volta inserita e proseguito con la configurazione, avremo questo risultato:
Nel caso l’utente Administrator sia stato disabilitato nel vostro Dominio AD, è possibile passare a realm il parametro –user=$nome_utente e, se necessario, impostare già l’inserimento del sistema RHEL nella corretta Organization Unit, utilizzando i parametri come in questo esempio:
# realm join --user=test -v --computer-ou=OU=Linux,OU=Server,DC=test,DC=local TEST.LOCAL
In questo caso, abbiamo effettuato la join al Dominio AD andando a posizionare il nostro sistema RHEL direttamente nella OU Server\Linux
Ora sarà possibile effettuare login sul nostro sistema RHEL utilizzando gli utenti AD sia in modalità GUI sia in modalità SSH, ma solo accedendo direttamente al sistema, quindi dobbiamo fare ancora un piccolo passo per poter utilizzare xRDP e fare login in modalità Desktop Remoto con gli utenti AD.
Andiamo ad inserire i seguenti parametri in /etc/sssd/sssd.conf
Riavviamo il servizio sssd con il comando:
# systemctl restart sssd
Se tutto è andato a buon fine, sarà ora possibile fare login via xRDP anche per gli utenti di Dominio AD:
Ora abbiamo il nostro sistema che ha fatto la join in Dominio Active Directory e gli utenti AD possono fare login sul nostro sistema RHEL attraverso xRDP.
Modifica del messaggio di login utente
In alcune situazioni, per regole Aziendali, può essere richiesto che, all’accesso dell’utente, venga presentato un messaggio informativo. In ambiente Windows è possibile gestirlo tramite GPO, in Linux è necessario effettuare questa impostazione da un lato, sulla configurazione del demone SSH, dall’altro sull’accesso in console.
Il file /etc/issue viene presentato come pre-login a tutti gli utenti che si presentano localmente al sistema, il suo contenuto è proposto direttamente all’utente al momento dell’accesso.
Nel caso venga effettuato l’accesso al server Linux mediante postazioni remote SSH, è possibile visualizzare anche a questi utenti il contenuto dello stesso file.
Questo comportamento del login tramite SSH è gestibile modificando la riga banner in /etc/ssh/sshd_config impostandola come questa:
Banner /etc/issue #viene rimosso il commento iniziale #
Dopo aver effettuato questa modifica, è necessario riavviare il demone SSH per renderla effettiva, quindi:
# systemctl restart sshd
Con questo è tutto, alla prossima!
