Recentemente abbiamo implementato una soluzione su un server Windows. Come di consueto, abbiamo creato collegamenti sul desktop per i dipendenti e abbiamo detto loro di iniziare a lavorare. Tuttavia, gli utenti si sono sentiti insicuri riguardo alla sicurezza informatica. Quando si collegavano al server, vedendo messaggi come: "Ci si fida di questo server? Sicuro sicuro?", si spaventavano e ci contattavano chiedendo se andava bene cliccare su OK. È stato deciso di rendere tutto più chiaro, così da evitare domande e panico.
Se i vostri utenti continuano a rivolgervi domande simili e siete stanchi di selezionare l'opzione "Non chiedere più", siete i benvenuti qui sotto.
Passo zero. Preparazione e questioni di fiducia
Quindi, il nostro utente clicca su un file salvato con estensione .rdp e riceve una richiesta del genere:
"Connessione sospetta".
Per eliminare questa finestra si utilizza un'utility 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.
- Rilasciato da un'autorità di certificazione interna.
- Completamente autofirmato.
La cosa principale è che il certificato deve avere la capacità di firmare (sì, può essere ritirato
dagli accountant della firma elettronica), e i PC client devono fidarsi di esso. Qui utilizzerò un certificato autofirmato.
Ricordo che la fiducia in un certificato autofirmato può essere organizzata tramite criteri di gruppo. Maggiori dettagli sotto spoiler.
Come rendere il certificato attendibile tramite la magia dei GPO
Per iniziare, è necessario prendere il certificato esistente senza chiave privata in formato .cer (questo può essere fatto esportando il certificato dall'agente 'Certificati') e posizionarlo in una cartella di rete accessibile in lettura agli utenti. Dopo di che, si può configurare la politica di gruppo.
L'importazione del certificato si configura nella sezione: Configurazione computer - Politiche - Configurazione Windows - Opzioni di sicurezza - Politiche della chiave pubblica - Autorità di certificazione delle radici fidate. Quindi facciamo clic con il tasto destro per importare il certificato.
Politica configurata.
Ora i PC client riconosceranno come attendibile il certificato autofirmato.
Se i problemi di fiducia sono risolti, passiamo direttamente alla questione della firma.
Primo passo. Firmiamo il file in modo ampio.
C'è un certificato, ora dobbiamo scoprire il suo hash. Apriamolo semplicemente nell'utility "Certificati" e copiamo dalla scheda "Dettagli".
L'hash di cui abbiamo bisogno.
È meglio portarlo subito nel formato corretto: solo lettere maiuscole e senza spazi, se presenti. Questo è facilmente realizzabile nella console PowerShell con il comando:
("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")
Una volta ottenuto l'hash nel formato richiesto, possiamo tranquillamente firmare 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 parte delle impostazioni tramite un'interfaccia grafica come il nome del server (in effetti, altrimenti quale sarebbe il senso della firma?). Se si modificano le impostazioni con un editor di testo, la firma "salta".
Ora, facendo doppio clic sull'icona, il messaggio sarà diverso:
Nuovo messaggio. Il colore è meno allarmante, già un progresso.
Eliminiamolo anche.
Secondo passo. E di nuovo domande sulla fiducia.
Per rimuovere questo messaggio, avremo nuovamente bisogno della policy di gruppo. Questa volta dobbiamo andare su Configurazione computer — Politiche — Modelli amministrativi — Componenti di Windows — Servizi Desktop remoto — Client di connessione Desktop remoto — Indica le impronte SHA1 dei certificati che rappresentano gli editori RDP attendibili.
La policy di cui abbiamo bisogno.
Nella policy è sufficiente aggiungere l'impronta già nota dal passaggio precedente.
È importante notare che questa policy sovrascrive la policy 'Consentire i file RDP da editori autorizzati e parametri RDP personalizzati definiti per impostazione predefinita'.
Politica configurata.
Ecco fatto, ora nessuna domanda strana — solo la richiesta di login e password. Hmm…
Passo tre. Accesso trasparente al server
In effetti, se ci siamo già autenticati accedendo a un computer del dominio, perché dovremmo reinserire la stessa login e password? Trasmettiamo i dati di accesso al server in modo 'trasparente'. Nel caso di RDP semplice (senza l'uso di RDS Gateway), ci aiuterà... giusto, la policy di gruppo.
Andiamo alla sezione: Configurazione del computer - Politiche - Modelli amministrativi - Sistema - Trasferimento delle credenziali - Consenti il trasferimento delle credenziali predefinite.
Qui è possibile aggiungere i server necessari alla lista oppure utilizzare un wildcard. Apparirà così TERMSRV/trm.contoso.com o TERMSRV/*.contoso.com.
Politica configurata.
Ora, se guardiamo la nostra scorciatoia, apparirà più o meno in questo modo:
Il nome utente non può essere cambiato.
Se si utilizza RDS Gateway, sarà anche necessario abilitare il trasferimento dei dati. Per fare ciò, nel gestore IIS è necessario disabilitare l'autenticazione anonima e abilitare l'autenticazione di Windows nelle 'Metodologie di autenticazione'.
IIS configurato.
Non dimenticare di riavviare i servizi web con il comando:
iisreset /noforce
Adesso va tutto bene, nessuna domanda o richiesta.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Racconta, firmi i collegamenti RDP ai tuoi utenti?
43%No, sono abituati a cliccare 'OK' nei messaggi senza leggere, alcuni mettono anche la spunta su 'Non chiedere più'.
29.2%Io metto sempre la scorciatoia manualmente e faccio il primo accesso al server insieme a ogni utente.
6.1%Certo, mi piace avere tutto in ordine.
21.5%Non utilizzo server terminali.
Hanno votato 65 utenti. 14 utenti si sono astenuti.
Fonte: habr.com
