Podkast 22T52 2 Scenariusze Uważaj na MS RDP – 802.1x oraz VPN

WERSJA TEKSTOWA

Cześć. Witam Cię w dzisiejszym odcinku mojego podkastu. Dzisiejszy temat to RDP i uwierzytelnienie 802.1x. Jeżeli chodzi o 802.1x to oczywiście typowo mamy dwa interfejsy bezprzewodowy i przewodowy a w RDP problem pojawia się gdy próbujemy uwierzytelnić do 802.1x użytkownikiem. Dlaczego się tak dzieje? Taki typowy scenariusz, który najczęściej widzę to jest uwierzytelnianie urządzenia tylko po certyfikacie lub identyfikatorze samego urządzenia. Wtedy konfliktu nie ma bo urządzenie jest podłączone do naszej sieci z identyfikatorem i jeśli potrzebujemy zestawić sesję RDP to nam wszystko działa. Trzeba mieć na uwadze, że RDP Windows’owe to nie jest tylko kwestia zdalnego pulpitu ale również uwierzytelnienia użytkownika i stworzenia dla niego sesji użytkownika.

Tutaj pojawia się problem, który uważam, że Microsoft mógłby rozwiązać ale najwyraźniej tego nie chciał zrobić. Chodzi o to, że jeśli testujemy, zwłaszcza przy wdrażaniu 802.1x nasz profil uwierzytelniania w oparciu o dostęp po RDP do danej stacji testowej to problem polega na tym, że użytkownik, który się loguje przez RDP nie jest właściwie identyfikowany przynajmniej w interfejsie przewodowym. To też jest ciekawe. Inaczej działa suplikant bezprzewodowy, czyli kawałek oprogramowania, który w Windows odpowiada za uwierzytelnienie do sieci bezprzewodowej a inaczej troszeczkę działa ten kawałek kodu, który dotyczy sieci przewodowej. Więc efekt tego jest taki, że jeśli próbujemy uwierzytelniać się do sieci przewodowej i jednocześnie mamy dostęp do tej stacji tylko po RDP np przez inny interfejs to w komunikacji Radiusowej widzimy informację, że użytkownik nie znany, nie można zidentyfikować bądź w ogóle żadnej komunikacji nie widzimy i to też jest ciekawe, że te różne typy zachowań suplikanta się bardzo różnią w zależności od scenariusza, który testujemy, w zależności od metody, którą przyjmiemy. Tutaj nie ma jakiejś wielkiej spójności.

Wniosek mój jest taki, że jeśli trzymasz się metody standardowej, najczęściej używanej to ten suplikant zapewne w miarę działa przewidywalnie i stabilnie. Natomiast jak już zaczynasz chcieć coś mniej standardowego wykorzystać to już różne rzeczy mogą się zadziać. W każdym razie gdybyś wdrażał u siebie 802.1x to polecam zdecydowanie środowisko testowe na którym to będziesz wykonywał z fizycznym dostępem. Dlatego, że przyśpiesza to i ułatwia cały proces i umożliwia łatwiejszy trouble-shooting a jeżeli chodzi o sesje RDP to jest ona w konflikcie z tożsamością użytkownika więc o ile tylko posługujesz się uwierzytelnieniem maszyny to w porządku. Natomiast w przypadku jak chciałbyś zrobić zaawansowany sposób uwierzytelniania czyli jednocześnie mieć informacje o użytkowniku i o uwierzytelnieniu maszyny czyli np omawiany wcześniej TEAP Microsoftu czy RFC to możemy oczywiście to wykonać ale wymagany jest dostęp fizyczny do tego urządzenia. Na tym należy się oprzeć.

Mówiąc potem o mapowaniu tego użytkownika, jeśli już podaje nam suplikant jego właściwą identyfikację to wtedy nie ma większego problemu. Możemy po stronie Radiusa sobie odpowiednią politykę stworzyć, mapowanie do AD jeżeli mamy taki scenariusz typowy i odpowiednie pole wykorzystać. Więc gdy będziesz planował takie rozwiązanie to proponuję skorzystaj z mojej porady, doświadczenia i przygotować sobie fizyczne środowisko tego testowania. W przypadku bezprzewodowego interfejsu zakładamy, że łączymy się przewodowym interfejsem do urządzenia zdalnego a bezprzewodowy suplikant konfigurujemy do uwierzytelniania i testujemy sobie różne właściwości.

To ciekawe, że tu nie mieliśmy jakiegoś większego problemu z tą tożsamością po RDP do suplikanta bezprzewodowego. Widać, że to jest inne traktowanie Windowsa w kontekście przewodowego suplikanta. Ten problem nie występuje tylko w przypadku 802.1x. Podobnie jest w przypadku np. VPNa. Gdy włączysz się VPNem w oparciu o AD, uwierzytelnia się ten użytkownik w oparciu o AD, spina sobie tunel i załóżmy, że wewnętrzna osoba z sieci korporacyjnej przez ten zestawiony tunel VPN chce się podłączyć do zdalnego komputera i chce to zrobić przez RDP, to się nie uda. Nie uda się z tego powodu, że rozpina się tunel. Jeśli mamy taką sytuacje, że tunel jest uzależniony od identyfikacji użytkownika i jego poświadczeń w AD a potem chcemy spiąć zdalną sesje RDP najczęściej na inne poświadczenia to w tym momencie jednocześnie możemy rozpiąć tunel. Tracimy sesję RDP, która się próbowała nawiązać, nie mamy wtedy podłączonego użytkownika po VPNie ani nie mamy sesji supportowej RDP do tego komputera. Cały proces nam nie działa.

Gdybyś chciał dla użytkowników zdalnych mieć możliwość konfiguracji zdalnego pulpitu to trzeba poszukać innego narzędzia do tego zdalnego pulpitu. Tu są różne opcje konfiguracji. Takie bardziej dla indywidualnych użytkowników jak Teamviewer. Są też narzędzia takie bardziej zintegrowane z systemami suportowymi dla przedsiębiorstw gdzie zdalny pulpit jest jednym z elementów takiego rozwiązania. To też można jak najbardziej użyć. Chodzi o to, żeby nie przełączać użytkownika, który jest podpięty VPNem – w oparciu o użytkownika – do tego procesu. Więc jeśli tylko pulpit zdalny i np. VNC sobie uruchomisz a użytkownik jest zalogowany, ma spięty tunel i jest to konto w Windowsie uruchomione, czyli działa ta sesja użytkownika to wtedy tym zdalnym pulpitem można się również podłączyć przez VNC, Teamviewer czy inne narzędzia. W zależności od tego co chcesz zrobić i jak chcesz wykorzystać warto mieć na uwadze, że ma Microsoftowy mechanizm RDP ma pewne zalety ale ma też pewne konsekwencje używania tej funkcjonalności w powiązaniu z logowaniem użytkownika.

Na dziś to tyle, dziękuje Ci za uwagę i do usłyszenia w kolejnym odcinku.