Nie tak dawno temu wdrożyliśmy rozwiązanie na serwerze terminali Windows. Jak zwykle wrzucili skróty do łączenia się z pulpitami pracowników i powiedzieli – praca. Okazało się jednak, że użytkownicy byli zastraszeni cyberbezpieczeństwem. A podczas łączenia się z serwerem wyświetlają się komunikaty typu: „Czy ufasz temu serwerowi? Dokładnie, dokładnie? ”, Przestraszyli się i zwrócili do nas - ale czy wszystko w porządku, czy mogę kliknąć OK? Potem postanowiono zrobić wszystko pięknie, żeby nie było pytań i paniki.

Jeśli Twoi użytkownicy nadal zwracają się do Ciebie z podobnymi obawami, a Ty masz już dość zaznaczania „Nie pytaj ponownie” – witaj w kategorii cat.

Krok zerowy. Kwestie szkoleń i zaufania

Zatem nasz użytkownik klika zapisany plik z rozszerzeniem .rdp i otrzymuje następujące żądanie:

Złośliwe połączenie.

Aby pozbyć się tego okna, użyj specjalnego narzędzia o nazwie RDPsign.exe. Pełna dokumentacja dostępna jest jak zwykle pod adresem Oficjalna strona, a my przeanalizujemy przykład użycia.

Najpierw musimy pobrać certyfikat, aby podpisać plik. On może być:

• Publiczny.
• Wystawiony przez wewnętrzny urząd certyfikacji.
• Całkowicie z podpisem własnym.

Najważniejsze, że certyfikat posiada możliwość podpisu (tak, można zaznaczyć
księgowi EDS), a komputery klienckie mu ufały. Tutaj użyję certyfikatu z podpisem własnym.

Przypomnę, że zaufanie do certyfikatu z podpisem własnym można zorganizować za pomocą zasad grupowych. Trochę więcej szczegółów - pod spoilerem.

Jak sprawić, by certyfikat był zaufany magii GPO

Najpierw należy pobrać istniejący certyfikat bez klucza prywatnego w formacie .cer (można to zrobić eksportując certyfikat z przystawki Certyfikaty) i umieścić go w folderze sieciowym dostępnym do odczytu dla użytkowników. Następnie możesz skonfigurować zasady grupy.

Import certyfikatu konfiguruje się w sekcji: Konfiguracja komputera - Zasady - Konfiguracja systemu Windows - Ustawienia zabezpieczeń - Zasady kluczy publicznych - Zaufane główne urzędy certyfikacji. Następnie kliknij prawym przyciskiem myszy, aby zaimportować certyfikat.

Skonfigurowana polityka.

Komputery klienckie będą teraz ufać certyfikatowi z podpisem własnym.

Jeśli problemy z zaufaniem zostaną rozwiązane, przechodzimy bezpośrednio do kwestii podpisu.

Krok pierwszy. Skrupulatnie podpisuje plik

Jest certyfikat, teraz musisz znaleźć jego odcisk palca. Wystarczy otworzyć go w przystawce „Certyfikaty” i skopiować na zakładkę „Skład”.

Potrzebujemy odcisku.

Lepiej od razu doprowadzić to do właściwej formy - tylko wielkimi literami i bez spacji, jeśli występują. Wygodnie jest to zrobić w konsoli PowerShell za pomocą polecenia:

("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")

Po otrzymaniu wydruku w żądanym formacie możesz bezpiecznie podpisać plik rdp:

rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp

Gdzie .contoso.rdp to bezwzględna lub względna ścieżka do naszego pliku.

Po podpisaniu pliku nie będzie już możliwości zmiany niektórych parametrów poprzez interfejs graficzny, np. nazwy serwera (właściwie, bo inaczej jaki sens ma podpisywanie?). A jeśli zmienisz ustawienia edytorem tekstu, to wtedy podpis „leci”.

Teraz, gdy klikniesz dwukrotnie na etykietę, komunikat będzie inny:

Nowa wiadomość. Kolor jest mniej niebezpieczny, już postęp.

Pozbądźmy się także jego.

Krok drugi. I znowu pytania o zaufanie

Aby pozbyć się tej wiadomości, ponownie potrzebujemy polityki grupowej. Tym razem droga leży w sekcji Konfiguracja komputera - Zasady - Szablony administracyjne - Składniki systemu Windows - Usługi pulpitu zdalnego - Klient podłączania pulpitu zdalnego - Określ odciski palców SHA1 certyfikatów reprezentujących zaufanych wydawców RDP.

Potrzebujemy polityki.

W polisie wystarczy dodać nadruk znany nam już z poprzedniego kroku.

Warto zauważyć, że ta zasada zastępuje zasadę „Zezwalaj na pliki RDP od prawidłowych wydawców i niestandardowe domyślne ustawienia RDP”.

Skonfigurowana polityka.

Voila, teraz nie ma dziwnych pytań - tylko prośba o hasło do logowania. Hm…

Krok trzeci. Przejrzyste logowanie do serwera

Rzeczywiście, jeśli zalogowaliśmy się już na komputerze domeny, to po co ponownie wpisywać ten sam login i hasło? Przekażmy dane uwierzytelniające do serwera „w sposób przezroczysty”. W przypadku prostego RDP (bez użycia RDS Gateway) z pomocą przyjdzie nam... Zgadza się, polityka grupowa.

Przechodzimy do sekcji: Konfiguracja komputera - Zasady - Szablony administracyjne - System - Przekazywanie poświadczeń - Zezwalaj na przesyłanie domyślnych poświadczeń.

Tutaj możesz dodać niezbędne serwery do listy lub użyć symbolu wieloznacznego. To będzie wyglądać TERMSRV/trm.contoso.com lub TERMINY/*.contoso.com.

Skonfigurowana polityka.

Teraz, jeśli spojrzymy na naszą etykietę, będzie ona wyglądać mniej więcej tak:

Nie zmieniaj nazwy użytkownika.

Jeśli używana jest bramka RDS, należy także zezwolić na przesyłanie danych. Aby to zrobić, w menedżerze IIS należy wyłączyć uwierzytelnianie anonimowe w „Metodach uwierzytelniania” i włączyć uwierzytelnianie systemu Windows.

skonfigurowane usługi IIS.

Nie zapomnij zrestartować usług internetowych za pomocą polecenia:

iisreset /noforce

Teraz wszystko jest w porządku, nie ma żadnych pytań i próśb.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Powiedz mi, czy podpisujesz etykiety RDP dla swoich użytkowników?

• 43%Nie, są szkoleni, jak naciskać „OK” w wiadomościach bez czytania, niektórzy nawet sami zaznaczają pola wyboru „Nie pytaj ponownie”.28

• 29.2%Ostrożnie umieszczam etykietę rękami i wraz z każdym użytkownikiem dokonuję pierwszego logowania do serwera.19

• 6.1%Oczywiście, że lubię wszystko w porządku.4

• 21.5%Nie korzystam z serwerów terminalowych.14

Głosowało 65 użytkowników. 14 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com