Więcej miejsc do posłuchania:
WERSJA TEKSTOWA
Cześć, witam Cię w moim odcinku podkastu, dzisiejszy temat to połączenie systemów NAC i RDP – konkretnie w wydaniu Microsoft – Remote Desktop Protocol. W czym jest problem? To może opowiem jak ostatnio spotkałem się w kilku sytuacjach z taką zależnością i okazuje się, że jest problem, który wynika z samej konstrukcji i idei funkcjonowania tego dostępu zdalnego pulpitu Microsoft’u.
Chodzi o to, że Microsoft wymyślając sobie pulpit zdalny założył, że jest on powiązany z tożsamością użytkownika. Jeżeli masz jakiś system i zdalnie się do niego logujesz przez RDP – system Windows’owy – to jesteś zalogowany jako jakiś użytkownik. Jeżeli natomiast patrzysz na specyfikę działania systemów NAC (to samo się tyczy systemów VPN’owych) to one używają tożsamości Windows’a. Oczywiście nie muszą ale jest to najczęściej stosowany mechanizm dlatego, żeby był łatwy dla użytkownika. Aby nie trzeba było nic wpisywać, żadnego użytkownika, hasła, tylko żeby się automatycznie ten komputer identyfikował i łączył z danym profilem.
Jeżeli używasz tej identyfikacji użytkownika do podłączenia np. w systemie NAC danego komputera do sieci to oznacza, że będziesz teraz chciał się posłużyć identyfikatorem sesji RDP. To jest scenariusz, który zakłada, że mamy np. sytuację z COVID’u jeszcze, czyli mamy użytkownika, który ma komputer stacjonarny w firmie ale pracuje teraz przynajmniej częściowo z domu i potrzebuje się łączyć w jakiś sposób do swojego komputera, który jest w firmie i korzystać z tego komputera zdalnie, ponieważ nie było tyle komputerów aby rozdać wszystkim nowe laptopy, na których mogą wszystko uruchomić.
W związku z tym, jeżeli masz taką sytuację, że zdalnie łączy się dany użytkownik do danego komputera a ten komputer stoi w naszej sieci korporacyjnej i uwierzytelnia się 802.1x do sieci to będziesz miał problem. Jednak będziesz miał problem tylko w momencie, kiedy uwierzytelniasz tego użytkownika do sieci, czyli system NAC działa w oparciu o identyfikację użytkownika. Jest jeszcze druga możliwość, możesz zidentyfikować samą stację jako maszynę i tak podłączać. Wtedy ten system RDP działa bez problemu. Jeśli rozmawiamy o systemie NAC to zakładamy że chcielibyśmy wiedzieć jedno i drugie.
Najlepsze rozwiązanie i najwyższy poziom bezpieczeństwa jest wtedy kiedy jesteśmy w stanie powiedzieć co to jest za maszyna, ona się uwierzytelnia i żebyśmy byli w stanie powiedzieć co to za użytkownik bo też on się uwierzytelnia. Jeśli takie tematy Cię interesują polecam rozważenie protokołu TIP – jest to protokół, który umożliwia dwu etapowe uwierzytelnianie. Jest on zestandaryzowany, można go używać i bardzo dobrze to działa. Możesz wtedy sobie sprawdzać czy znasz urządzenie i użytkownika. W zależności od tego jaka jest kombinacja tych dwóch czynników, podłączasz odpowiednim profilem urządzenie.
Wracając teraz do RDP – jeżeli się nim łączysz i korzystasz np. z TIP’a czyli tych dwóch kroków uwierzytelnienia to będziesz miał problem pod tytułem brak przekazywania informacji o użytkowniku. Dlatego, że Microsoft zaimplementował ten protokół RDP w taki sposób, że on nie mapuje tego sposobu identyfikacji użytkownika Windowsa dokładnie w taki sam sposób jak lokalnie zalogowany użytkownik. Więc jeśli masz np. system Radius i będziesz chciał sobie zobaczyć logowanie takiego użytkownika zdalnego i będzie on używał dostępu RDP do swojego komputera to będziesz miał najczęściej informacje: anonimowy użytkownik, nieznany użytkownik, nie można było uwierzytelnić, takie różne dziwne komunikaty.
To wynika ze sposobu w jakim funkcjonuje sam Windows. Jeżeli łączy się RDP’em do niego użytkownik i potem identyfikacja tego użytkownika ma być użyta do 802.1x, to to nie działa. Tu nie zależnie od tego czy używasz certyfikatu to nie działa. Opcje masz dwie. Albo możesz zrezygnować z uwierzytelniania użytkownikiem w 802.1x i uwierzytelniać maszynę i to działa, tak możesz zrobić. Tyle tylko, że nie wiesz wtedy kto tam się loguje. Każdy kto ma konto na tej maszynie będzie mógł się logować do sieci tym samym poziomem uprawnień. To generalnie nie jest dobre.
Możliwość druga – wybrać inny system czy mechanizm połączenia zdalnego z tym komputerem. To jest raczej opcja, którą ja polecam – czyli nie trzeba się koniecznie wiązać z tym jak Microsoft zaimplementował ten zdalny pulpit. Można rozważyć inne narzędzie, które umożliwi logowanie do tego komputera i wtedy on jest traktowany np jakimś zdalnym dostępem, zdalnym pulpitem, jakimiś innymi narzędziami, które można użyć i on jest wtedy logowany jako ten użytkownik lokalny i wtedy ta cała mechanika logowania, przekazywania informacji o użytkowniku działa.
To jest jedna możliwość, druga – też mało atrakcyjna, przynajmniej z mojego punktu widzenia jest taka, że użytkownik może mieć inne poświadczenia. Nie wiążemy wtedy z identyfikacją konkretnie domenową, nie mówimy wtedy, że te same poświadczenia co na komputerze masz użyć do 802.1x, tylko mówimy, że osobno będziemy wpisywać dane. To jest możliwe do zrobienia, natomiast to przekłada pewien ciężar użytkowania na użytkownika. To generalnie nie jest dobre rozwiązanie bo chcemy, żeby ten użytkownik miał jak najlepsze poczucie korzystania z tej infrastruktury bo jeżeli mu dołożymy zadań to oznacza, że ma on więcej problemów, więcej problemów zgłasza do nas a my mamy więcej pracy. Jest to mało satysfakcjonujący scenariusz.
Jeśli masz co do tego jakieś pytania to oczywiście pisz w komentarzu, to jest rzecz, którą ja wypraktykowowałem ostatnimi czasy w różnych projektach i ewidentnie należy mieć na uwadze, że RDP w wydaniu Microsoftu nie działa świetnie z przekazywaniem poświadczeń o użytkowniku do innych systemów. Niezależnie od scenariusza, jeśli masz tego typu problem, że coś się nie uwierzytelnia a środowisko labowe masz zdalne to rozważ czy inaczej się do tego środowiska dostawać albo nie mieć tego środowiska dostępnego fizycznie, lokalnie. Na tyle dzisiaj, dziękuję Ci za uwagę i do usłyszenia już za tydzień.
