Non molto tempo fa abbiamo implementato una soluzione su un server terminale Windows. Come al solito, abbiamo messo delle scorciatoie sui desktop dei dipendenti per la connessione e abbiamo detto: "lavorate pure". Ma gli utenti erano spaventati riguardo alla Sicurezza Informatica. E quando si connettevano al server, vedendo messaggi del tipo: "Fidatevi di questo server? Sicuri sicuri?", si spaventavano e si rivolgeva a noi per chiedere se andasse tutto bene e se potessero premere OK. Così è stato deciso di rendere tutto più semplice, per non avere più domande e panico.
Se i vostri utenti continuano a venirvi incontro con queste paure e vi siete stancati di spuntare la casella "Non chiedere più" — benvenuti sotto il cat.
Passo zero. Preparazione e questioni di fiducia
Quindi, il nostro utente clicca su un file salvato con estensione .rdp e riceve questa richiesta:
"Collegamento potenzialmente dannoso".
Per eliminare questa finestra si utilizza un'utilità speciale chiamata RDPSign.exe. La documentazione completa è disponibile, come al solito, su , e noi esamineremo un esempio di utilizzo.
Per iniziare, dobbiamo ottenere un certificato per firmare il file. Può essere:
- Pubblico.
- Emesso da un'autorità interna di certificazione.
- Completamente auto-firmato.
La cosa più importante è che il certificato abbia la possibilità di firmare (sì, è possibile prenderlo
dai contabili della firma digitale), e che i PC client si fidino di esso. Qui utilizzerò un certificato auto-firmato.
Ricordo che la fiducia in un certificato auto-firmato può essere organizzata tramite politiche di gruppo. Maggiori dettagli — sotto spoiler.
Come rendere un certificato affidabile usando la magia delle GPO
Per prima cosa, bisogna prendere il certificato esistente senza la chiave privata in formato .cer (questo può essere fatto esportando il certificato dalla console "Certificati") e metterlo in una cartella di rete accessibile agli utenti in sola lettura. Dopo di che, si può configurare la politica di gruppo.
L'importazione del certificato è configurata nella sezione: Configurazione computer — Politiche — Configurazione Windows — Impostazioni di sicurezza — Politiche della chiave pubblica — Centri di certificazione radice fidati. Poi con il tasto destro importiamo il certificato.
Politica configurata.
Ora i PC client si fideranno del certificato auto-firmato.
Se i problemi di fiducia sono risolti, passiamo direttamente alla questione della firma.
Passo uno. Firmiamo il file con un colpo deciso
Il certificato è presente, ora dobbiamo ottenere il suo fingerprint. Apriamolo semplicemente nell'applet "Certificati" e copiamo nella scheda "Contenuto".
Il fingerprint di cui abbiamo bisogno.
È meglio trasformarlo subito nel formato corretto: solo lettere maiuscole e senza spazi se ci sono. È comodo farlo nella console di PowerShell con il comando:
("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")
Una volta ottenuto il fingerprint nel formato corretto, possiamo firmare senza esitazioni il file rdp:
rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp
Dove .contoso.rdp è il percorso assoluto o relativo al nostro file.
Dopo che il file è stato firmato, non sarà più possibile modificare alcune impostazioni tramite interfaccia grafica, come il nome del server (in effetti, altrimenti qual è il senso di firmare?). Se invece si cambiano le impostazioni tramite un editor di testo, la firma "salta".
Ora, facendo doppio clic sull'icona, il messaggio sarà diverso:
Nuovo messaggio. Il colore è meno pericoloso, già un progresso.
Liberiamoci anche di questo.
Passo due. E ancora domande di fiducia
Per sbarazzarci di questo messaggio, avremo nuovamente bisogno della policy di gruppo. Questa volta, il percorso è: Configurazione computer - Politiche - Modelli amministrativi - Componenti di Windows - Servizi desktop remoto - Client di connessione al desktop remoto - Specificare i fingerprint SHA1 dei certificati che rappresentano editori RDP autorizzati.
La policy che ci serve.
Nella policy è sufficiente aggiungere il fingerprint già noto dal passo precedente.
È importante notare che questa policy sovrascrive la policy "Consentire file RDP da editori autorizzati e opzioni utente RDP impostate per impostazione predefinita".
Politica configurata.
Voilà, ora nessuna strana domanda – solo una richiesta di login e password. Hmm...
Passo tre. Accesso trasparente al server
Infatti, se ci siamo già autenticati accedendo a un computer di dominio, perché dovremmo reinserire lo stesso login e password? Trasmettiamo quindi in modo "trasparente" le credenziali al server. Nel caso di un semplice RDP (senza l'uso di RDS Gateway), ci aiuterà... Già, la policy di gruppo.
Andiamo nella sezione: Configurazione computer - Politiche - Modelli amministrativi - Sistema - Trasmissione delle credenziali - Consentire la trasmissione delle credenziali impostate per impostazione predefinita.
Qui puoi aggiungere i server necessari alla lista o utilizzare un wildcard. Questo apparirà come TERMSRV/trm.contoso.com o TERMSRV/*.contoso.com.
Politica configurata.
Ora, se guardiamo la nostra scorciatoia, dovrebbe apparire più o meno così:
Il nome utente non può essere cambiato.
Se utilizzi RDS Gateway, dovrai anche abilitare il trasferimento dei dati. Per questo, nel gestore IIS, devi disabilitare la verifica anonima e abilitare la verifica di Windows nelle "Metodologie di autenticazione".
IIS configurato.
Non dimenticare di riavviare i servizi web con il comando:
iisreset /noforce
Ora tutto funziona bene, nessuna domanda e richiesta.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Raccontami, firmi le scorciatoie RDP per i tuoi utenti?
43%No, sono abituati a premere "OK" nei messaggi senza leggere, alcuni persino spuntano "Non chiedere più".
29.2%Metto manualmente le scorciatoie e faccio il primo accesso al server insieme a ciascun utente.
6.1%Certo, mi piace avere tutto in ordine.
21.5%Non utilizzo server terminali.
Sono stati votati da 65 utenti. 14 utenti si sono astenuti.
Fonte: habr.com
