Dostęp VPN bez uprawnień do pulpitu zdalnego: cztery osobne bramy

Użytkownik łączy się z VPN, otwiera udział plików i aplikację wewnętrzną, a następnie próba RDP zwraca „konto użytkownika nie jest upoważnione do zdalnego logowania”. W tym komunikacie nic nie jest nie tak z tunelem. Między kontem VPN a interaktywnym pulpitem stoją cztery niezależne bramy i tylko ostatnia to spowodowała. Ludzie zwykle reagują, dodając konto do grupy Administrators, co daje znacznie więcej niż pulpit i nie naprawia bramy, jeśli zasady grupy jej zabraniają. Oto co naprawdę robi każda brama i jak zmienić tylko tę, która odmawia.

Cztery bramy w stałej kolejności

Brama najpierw decyduje, czy tożsamość może w ogóle ustanowić tunel: polityka RADIUS, warunek grupy, sprawdzenie certyfikatu, uprawnienie Access Server. Potem routing i zapory decydują, czy pakiet z puli tunelu dociera do odbiornika TCP 3389 celu. Potem uzgadnianie NLA klienta uwierzytelnia konto wobec celu. Dopiero po tych trzech lokalny organ zabezpieczeń sprawdza, czy konto ma uprawnienie logowania wymagane przez interaktywną sesję zdalną.

Ponieważ kolejność jest stała, każda brama ukrywa te za nią. Nieudany tunel nic nie mówi o routingu; zablokowany port nic nie mówi o uprawnieniu logowania; udany test portu nic nie mówi o dopuszczeniu. Dlatego „VPN działa, ale RDP nie” nie jest jednym problemem, lecz granicą między dwiema z tych bram, i dlatego tekst błędu jest najszybszym sposobem ustalenia, na którą trafiłeś.

Uprawnienie, które naprawdę odrzuca sesję

Logowanie do pulpitu zdalnego wymaga uprawnienia użytkownika Zezwalaj na logowanie przez Usługi pulpitu zdalnego, SeRemoteInteractiveLogonRight. Jest ono sprawdzane przy logowaniu, a nie przy tworzeniu tunelu, więc konto może godzinami przeglądać sieć i nadal odmówić mu pulpitu. Dialog, który je pokazuje, znajduje się w Zasadach lokalnych, Przypisywanie praw użytkowników, a odpowiednik domenowy jest w obiekcie GPO.

Domyślne członkostwo zależy od roli komputera: stacje robocze i serwery członkowskie przyznają je grupom Administrators i Remote Desktop Users, natomiast kontroler domeny tylko grupie Administrators. Ten jeden fakt wyjaśnia większość zamieszania, ponieważ to samo konto odnosi sukces na serwerze plików, a zawodzi na DC. Prawo odmowy przeważa nad odpowiednim prawem zezwolenia niezależnie od członkostwa w grupie, więc konto, które ma jednocześnie zezwolenie i odmowę, jest odrzucane. Szeroka grupa odmowy może złapać administratora dodanego z uprzejmości.

Czytaj obowiązującą politykę, nie lokalny dialog

Politykę lokalną zastępuje każdy obiekt GPO domeny, który definiuje to samo uprawnienie, więc lokalny przystawka może pokazywać poprawnie wyglądającą listę, podczas gdy stan rzeczywisty jest inny. Wyeksportuj to, co komputer naprawdę stosuje, następnie znajdź uprawnienie i czytaj identyfikatory SID zamiast nazw wyświetlanych:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

W tym wyniku *S-1-5-32-544 to Administrators, a *S-1-5-32-555 to Remote Desktop Users.

Jeśli nie pojawi się żadne z nich, nikt poza posiadaczem polityki nie może otworzyć pulpitu, niezależnie od tego, co sugeruje lokalny dialog Użytkownicy i grupy. Wtedy gpresult wskazuje obiekt GPO, który zwyciężył, i to jest obiekt, który trzeba edytować; zmiana polityki lokalnej na komputerze przyłączonym do domeny to test, a nie naprawa.

Przyznaj najwęższe pasujące uprawnienie

Zwykłą odpowiedzią jest grupa Remote Desktop Users w celu. Nosi ona uprawnienie domyślnie, jest znacznie mniejsza niż Administrators i oddziela „może otworzyć pulpit” od „może zarządzać serwerem”. Tam, gdzie polityka wyraźnie przydzieliła uprawnienie ponownie, dodaj grupę lub konto do tej polityki, zamiast dodawać grupę, której nikt nie zamierzał używać jako kontroli dostępu.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

Sprawdź listę odmów, zanim cokolwiek dodasz. Jeśli prawo odmowy wymienia grupę zawierającą użytkownika, właściwą zmianą jest usunięcie konta z tej grupy lub zawężenie odmowy, a nie dodanie drugiego zezwolenia gdzie indziej. Zapisz, które uprawnienie i gdzie zmieniłeś, ponieważ późniejsze odświeżenie GPO po cichu przywróci poprzedni stan, a zgłoszenie otworzy się ponownie z tym samym komunikatem.

Utrzymuj ścieżkę sieciową jako osobną decyzję

Grupa VPN nie musi docierać do każdego portu. Gdy grupa potrzebuje aplikacji, a nie pulpitu, reguła zapory ograniczona do puli tunelu i portu aplikacji nadaje tej polityce skuteczność, podczas gdy uprawnienie logowania pozostaje nietknięte.

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

Własna konfiguracja OpenVPN na klienta i uprawnienia grup Access Server mogą w tym samym duchu ograniczać prefiksy celu; żadne z nich nie przyznaje uprawnienia logowania Windows, a uprawnienie logowania nie może otworzyć portu. Trzymaj je w osobnych oknach zmian, ponieważ regułę portu i uprawnienie zatwierdzają różni ludzie.

Weryfikuj w tej samej kolejności, w jakiej działają bramy: czy konto może ustanowić tunel, czy sesja dociera do odbiornika, czy klient się uwierzytelnia i czy konto ma uprawnienie. Ping, który zawodzi, podczas gdy test portu się udaje, to zapora odpowiadająca inaczej na ICMP, a nie dowód, że RDP jest zablokowany. Dokumentacja Microsoftu dotycząca uprawnienia logowania wymienia wartości domyślne według roli komputera i regułę, że odmowa przeważa nad zezwoleniem.