Brak dostępu do udziałów SMB z sesji zdalnej

Brak dostępu do udziałów SMB z sesji zdalnej (RDP) wskazuje na ograniczenie "podwójnego przeskoku" (double hop) w uwierzytelnianiu Windows — wymaga konfiguracji delegowania poświadczeń (CredSSP).

Czym jest brak dostępu do udziałów SMB z sesji zdalnej

Brak dostępu do udziałów SMB z sesji zdalnej oznacza sytuację, w której zasób udostępniony w sieci lokalnej działa poprawnie przy bezpośrednim logowaniu do komputera, lecz przestaje być osiągalny po połączeniu przez RDP. Użytkownik może zalogować się do zdalnego pulpitu, otworzyć część programów i korzystać z lokalnych plików, ale próba wejścia do ścieżki sieciowej, na przykład w formacie \\nazwa-komputera\udział, kończy się odmową dostępu, żądaniem ponownego podania hasła albo komunikatem o braku uprawnień.

Źródłem problemu bywa sposób przekazywania tożsamości pomiędzy kolejnymi komputerami. Podczas logowania przez RDP poświadczenia użytkownika są używane do nawiązania pierwszej sesji, natomiast ich automatyczne wykorzystanie przy dostępie do następnego zasobu sieciowego może zostać zablokowane. W efekcie konto, które formalnie ma prawa do udziału, nie jest skutecznie rozpoznawane przy drugim połączeniu.

Nie jest to więc zwykle awaria samego protokołu SMB ani dowód na uszkodzenie plików. Należy rozróżnić uwierzytelnienie do zdalnego pulpitu od autoryzacji do konkretnego udziału. Pierwsze może przebiegać prawidłowo, podczas gdy drugie zatrzymuje się na granicy między sesją RDP a kolejnym komputerem w sieci.

Kontekst techniczny i porównanie sposobów uwierzytelniania - Brak dostępu do udziałów SMB z sesji zdalnej

W przypadku pracy lokalnej użytkownik loguje się bezpośrednio do systemu, a dostęp do udziału SMB jest sprawdzany w przewidywalnym kontekście konta. Przy RDP pojawia się dodatkowe ogniwo: komputer, z którego prowadzona jest sesja, oraz komputer, na którym znajduje się udostępniony katalog. Gdy tożsamość nie może zostać przekazana dalej, powstaje tak zwany problem podwójnego przeskoku uwierzytelniania.

Znaczenie ma również zastosowany mechanizm logowania. CredSSP może przekazać dane potrzebne do ustanowienia sesji zdalnej, ale nie oznacza to automatycznie, że te same dane zostaną delegowane do kolejnego zasobu. W środowiskach opartych na domenie można stosować kontrolowane delegowanie poświadczeń, jednak wymaga ono zgodności ustawień kont, komputerów, zasad bezpieczeństwa i usług. Przy zwykłych kontach lokalnych przekazywanie tożsamości jest jeszcze bardziej ograniczone.

Warto porównać kilka objawów. Jeżeli udział otwiera się po zalogowaniu bezpośrednio na komputerze docelowym, lecz nie działa przez RDP, podejrzenie pada na delegowanie lub kontekst sesji. Jeżeli nie działa również lokalnie, należy sprawdzić udział, uprawnienia systemu plików, zaporę i stan usługi odpowiedzialnej za udostępnianie. Gdy dostęp jest możliwy po ręcznym użyciu innych danych logowania, problem może dotyczyć mapowania kont, zapisanych poświadczeń albo różnicy między nazwą użytkownika domenowego i lokalnego.

Przy analizie nie powinno się ograniczać do samej listy uprawnień. Dostęp do pliku zależy jednocześnie od praw udziału i praw systemu plików, a skuteczne uprawnienie jest wynikiem ich połączenia. Dodatkowo znaczenie mogą mieć zasady dotyczące logowania interaktywnego, ograniczenia przekazywania poświadczeń, rozpoznawanie nazwy komputera oraz sposób uruchamiania aplikacji w sesji zdalnej.

Typowe problemy i błędy prowadzące do odmowy dostępu - Brak dostępu do udziałów SMB z sesji zdalnej

Częstym błędem jest uznanie, że poprawne zalogowanie do RDP powinno zapewnić dostęp do wszystkich zasobów widocznych z komputera lokalnego. Sesja zdalna może mieć inny zestaw poświadczeń, inny zakres uprawnień i inne zasady bezpieczeństwa. Dotyczy to zwłaszcza sytuacji, w której komputer zdalny próbuje połączyć się z trzecim urządzeniem w sieci.

Problemy mogą powodować także niejednoznaczne nazwy kont. Konto zapisane jako UŻYTKOWNIK, KOMPUTER\UŻYTKOWNIK i DOMENA\UŻYTKOWNIK nie zawsze jest traktowane jako ta sama tożsamość. Podobny efekt może wystąpić po zmianie hasła, wygaśnięciu zapisanych danych logowania lub pozostawieniu nieaktualnego wpisu w Menedżerze poświadczeń.

W praktyce spotyka się również błędne mapowanie dysków sieciowych. Dysk podłączony w jednej sesji użytkownika nie musi być widoczny w innej sesji, a mapowanie wykonane z podwyższonymi uprawnieniami może nie pojawić się w zwykłym Eksploratorze plików. Zamiast oceniać sytuację wyłącznie po ikonie dysku, należy sprawdzić dostęp do udziału przy użyciu pełnej ścieżki UNC oraz ustalić, w jakim kontekście uruchomiono polecenie.

Odmowę mogą powodować także ustawienia zasad grupy, ograniczenia NTLM, wyłączone lub nieprawidłowo działające usługi sieciowe, błędna rozdzielczość nazw, profil zapory albo różnice czasu między komputerami. W środowisku domenowym istotne jest sprawdzenie relacji z kontrolerem domeny i aktualności zasad. W środowisku bez domeny trzeba dokładniej zweryfikować zgodność kont oraz ręcznie wskazanych danych logowania.

Do diagnostyki przydatne są dzienniki systemowe, test połączenia z nazwą i adresem urządzenia, sprawdzenie odpowiedzi na port związany z udostępnianiem plików oraz porównanie zachowania przy logowaniu lokalnym i przez RDP. Zmiany w zasadach delegowania powinny być wprowadzane ostrożnie, ponieważ zbyt szerokie przekazywanie poświadczeń zwiększa ryzyko przejęcia dostępu do innych zasobów.

Kiedy warto skorzystać z pomocy serwisu - Brak dostępu do udziałów SMB z sesji zdalnej

Zgłoszenie do serwisu jest uzasadnione, gdy udział działa tylko w wybranym typie sesji, odmowa pojawia się po zmianie konfiguracji RDP albo nie da się jednoznacznie ustalić, które konto jest używane przy dostępie do zasobu. Szczególnej uwagi wymaga sytuacja, w której kilka komputerów korzysta z tych samych udziałów, a problem dotyczy tylko jednego stanowiska lub jednego użytkownika.

Przy zgłoszeniu warto opisać kolejność czynności: sposób uruchomienia sesji, nazwę użytego konta, dokładny komunikat, ścieżkę udziału oraz informację, czy zasób otwiera się przy bezpośrednim logowaniu. Pomocne jest także wskazanie, czy problem występuje przy nazwie komputera, adresie IP, mapowanym dysku i ręcznie podanych poświadczeniach. Takie dane skracają poszukiwanie przyczyny i ograniczają ryzyko przypadkowego zmieniania uprawnień.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie konfiguracji sesji zdalnej, kont użytkowników, udziałów SMB, zasad bezpieczeństwa oraz komunikacji między urządzeniami. W przypadku laptopa pierwszym etapem może być darmowa diagnoza LAPTOPA, dzięki której da się oddzielić problem systemowy od błędu sieci lub ustawień po stronie drugiego komputera.

Po ustaleniu przyczyny należy wdrożyć rozwiązanie adekwatne do środowiska: uporządkować dane logowania, skorygować uprawnienia, poprawić mapowanie zasobu, przywrócić właściwe zasady przekazywania tożsamości albo zmienić sposób dostępu do plików. Nie powinno się omijać odmowy przez trwałe zapisywanie haseł w skryptach ani przez nadawanie wszystkim użytkownikom pełnych praw, ponieważ takie działania mogą usunąć objaw kosztem bezpieczeństwa.