Niedawno wdrożyliśmy rozwiązanie na serwerze terminalowym Windows. Jak to zwykle bywa, wrzuciliśmy na biurka pracowników skróty do połączenia i powiedzieliśmy — pracujcie. Jednak użytkownicy byli przestraszeni kwestią bezpieczeństwa cybernetycznego. Przy połączeniu z serwerem, widząc komunikaty typu: „Czy ufasz temu serwerowi? Na pewno?”, czuli strach i zwracali się do nas — czy wszystko jest w porządku, czy można kliknąć OK? Wtedy postanowiono, aby wszystko wyglądało ładnie i nie budziło żadnych wątpliwości ani paniki.
Jeśli Twoi użytkownicy wciąż przychodzą do Ciebie z podobnymi obawami, a Ty masz dość zaznaczania opcji „Nie pytaj więcej” — zapraszamy do dalszej lektury.
Krok zerowy. Przygotowanie i pytania dotyczące zaufania
Zatem nasz użytkownik klika na zapisany plik z rozszerzeniem .rdp i otrzymuje takie oto zapytanie:
„Złośliwe” połączenie.
Aby pozbyć się tego okna, używana jest specjalna aplikacja o nazwie RDPSign.exe. Pełna dokumentacja jest dostępna, jak zwykle, na , a my omówimy przykład użycia.
Na początek musimy zdobyć certyfikat do podpisywania pliku. Może być:
- Publiczny.
- Wydany przez wewnętrzną służbę Certificate Authority.
- Całkowicie samopodpisany.
Najważniejsze, aby certyfikat miał możliwość podpisywania (tak, można to zabrać
od księgowych ECP), a stacje robocze użytkowników mu ufały. Tutaj będę używać samopodpisanego certyfikatu.
Przypominam, że zaufanie do samopodpisanego certyfikatu można zorganizować przy pomocy zasad grupowych. Trochę więcej szczegółów — w spoilerze.
Jak uczynić certyfikat zaufanym za pomocą magii GPO
Na początek potrzebujemy obecnego certyfikatu bez klucza prywatnego w formacie .cer (można to zrobić, eksportując certyfikat z narzędzia „Certyfikaty”) i umieścić go w udziale sieciowym dostępnym dla użytkowników do odczytu. Po tym można skonfigurować politykę grupową.
Import certyfikatu jest konfigurowany w sekcji: Konfiguracja komputera — Polityki — Konfiguracja Windows — Ustawienia zabezpieczeń — Polityki klucza publicznego — Zaufane główne jednostki certyfikacji. Następnie klikamy prawym przyciskiem myszy, aby zaimportować certyfikat.
Skonfigurowana polityka.
Teraz stacje robocze użytkowników będą ufać samopodpisanemu certyfikatowi.
Jeśli problemy z zaufaniem zostały rozwiązane, przechodzimy bezpośrednio do kwestii podpisywania.
Pierwszy krok. Zdecydowanie podpisujemy plik
Certyfikat już jest, teraz musimy poznać jego odcisk. Po prostu otworzymy go w narzędziu „Certyfikaty” i skopiujemy na zakładce „Skróty”.
Potrzebny nam odcisk.
Lepiej od razu doprowadzić go do porządku — tylko wielkie litery i bez spacji, jeśli są. Można to wygodnie zrobić w konsoli PowerShell poleceniem:
("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")
Po uzyskaniu odcisku w odpowiednim formacie, można śmiało podpisać plik rdp:
rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp
Gdzie .contoso.rdp to absolutna lub względna ścieżka do naszego pliku.
Po podpisaniu pliku nie będziemy mogli już zmienić części parametrów za pomocą interfejsu graficznego, jak nazwa serwera (w końcu, po co podpisywać?). A jeśli zmienimy ustawienia edytorem tekstu, podpis „zniknie”.
Teraz po podwójnym kliknięciu ikony komunikat będzie inny:
Nowa wiadomość. Kolor mniej niebezpieczny, już postęp.
Pozbądźmy się i tego.
Drugi krok. Znowu pytania o zaufanie
Aby pozbyć się tego komunikatu, znów będziemy potrzebować polityki grupowej. Tym razem droga prowadzi do sekcji Konfiguracja komputera — Polityki — Szablony administracyjne — Komponenty Windows — Usługi pulpitu zdalnego — Klient pulpitu zdalnego — Określenie odcisków SHA1 certyfikatów reprezentujących zaufanych wydawców RDP.
Potrzebna nam polityka.
W polityce wystarczy dodać nam znany odcisk z poprzedniego kroku.
Warto zauważyć, że ta polityka przysłania politykę „Zezwalaj na pliki RDP od dozwolonych wydawców oraz domyślne ustawienia RDP”.
Skonfigurowana polityka.
Voila, teraz żadnych dziwnych pytań — tylko prośba o login i hasło. Hm...
Trzeci krok. Przezroczysty dostęp do serwera
Rzeczywiście, jeśli już zalogowaliśmy się na komputerze domenowym, to po co wprowadzać ponownie ten sam login i hasło? Przekażmy dane uwierzytelniające na serwer „przezroczysto”. W przypadku prostego RDP (bez użycia RDS Gateway) na pomoc przychodzi... Tak, to polityka grupowa.
Idziemy do sekcji: Konfiguracja komputera — Polityki — Szablony administracyjne — System — Przekazywanie danych uwierzytelniających — Zezwól na przekazywanie danych uwierzytelniających ustalonych domyślnie.
Tutaj możesz dodać potrzebne serwery do listy lub skorzystać z wildcard. To będzie wyglądać jak TERMSRV/trm.contoso.com lub TERMSRV/*.contoso.com.
Skonfigurowana polityka.
Teraz, jeśli spojrzysz na naszą ikonę, będzie ona wyglądać mniej więcej tak:
Nazwy użytkownika nie można zmienić.
Jeśli używasz RDS Gateway, musisz również zezwolić na przekazywanie danych. W tym celu w menedżerze IIS należy w sekcji „Metody uwierzytelniania” wyłączyć uwierzytelnianie anonimowe i włączyć uwierzytelnianie Windows.
Skonfigurowany IIS.
Nie zapominaj, aby po zakończeniu zrestartować usługi internetowe poleceniem:
iisreset /noforce
Teraz wszystko jest w porządku, żadnych pytań i zapytań.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Powiedz, czy podpisujesz skróty RDP dla swoich użytkowników?
43%Nie, są przyzwyczajeni do klikania „OK” w komunikatach bez czytania, niektórzy nawet sami zaznaczają opcje „Nie pytaj więcej”.28
29.2%Ja sam ostrożnie wkładam skrót i pierwsze logowanie na serwerze robię razem z każdym użytkownikiem.19
6.1%Oczywiście, lubię mieć wszystko w porządku.4
21.5%Nie używam serwerów terminalowych.14
Zagłosowało 65 użytkowników. 14 użytkowników wstrzymało się od głosu.
Źródło: habr.com
