원격 데스크톱 권한 없이 VPN 접속하기: 네 개의 별도 관문

사용자가 VPN에 연결해 파일 공유와 내부 애플리케이션을 연 뒤 RDP를 시도하면 «사용자 계정은 원격 로그온에 권한이 없습니다»라는 메시지가 돌아옵니다. 그 메시지에 터널 문제는 없습니다. VPN 계정과 대화형 데스크톱 사이에는 네 개의 독립적인 관문이 있고, 그중 마지막 하나만 이 메시지를 만들었습니다. 사람들은 보통 계정을 Administrators에 추가하지만, 이는 데스크톱보다 훨씬 많은 권한을 주고 그룹 정책이 거부하는 경우 관문을 고치지 못합니다. 각 관문이 실제로 하는 일과 거부하는 하나만 바꾸는 방법은 다음과 같습니다.

네 관문은 고정된 순서로 놓인다

게이트웨이는 먼저 이 ID가 터널을 만들 수 있는지 결정합니다. RADIUS 정책, 그룹 조건, 인증서 검사, Access Server 권한입니다. 다음으로 라우팅과 방화벽이 터널 풀에서 온 패킷이 대상의 TCP 3389 수신기에 도달하는지 결정합니다. 다음으로 클라이언트의 NLA 핸드셰이크가 대상에 대해 계정을 인증합니다. 이 세 단계 뒤에야 로컬 보안 기관이 대화형 원격 세션에 필요한 로그온 권한을 계정이 보유하는지 확인합니다.

순서가 고정되어 있으므로 각 관문은 뒤에 있는 관문을 가립니다. 실패한 터널은 라우팅에 대해 아무것도 말하지 않습니다. 막힌 포트는 로그온 권한에 대해 아무것도 말하지 않습니다. 성공한 포트 테스트는 입장에 대해 아무것도 말하지 않습니다. 그래서 «VPN은 되는데 RDP는 안 된다»는 하나의 문제가 아니라 이 관문들 중 둘 사이의 경계이며, 그래서 오류 텍스트가 어느 관문에 부딪혔는지 아는 가장 빠른 방법입니다.

세션을 실제로 거부하는 권한

원격 데스크톱 로그온에는 사용자 권한 원격 데스크톱 서비스를 통한 로그온 허용, 즉 SeRemoteInteractiveLogonRight이 필요합니다. 이 권한은 터널을 만들 때가 아니라 로그온할 때 확인되므로, 계정이 몇 시간 동안 네트워크를 돌아다녀도 데스크톱을 거부당할 수 있습니다. 이 권한을 보여 주는 대화 상자는 로컬 정책, 사용자 권한 할당 아래에 있고, 도메인 해당 항목은 GPO에 있습니다.

기본 구성원 자격은 컴퓨터의 역할에 따라 다릅니다. 워크스테이션과 구성원 서버는 Administrators와 Remote Desktop Users에 부여하고, 도메인 컨트롤러는 Administrators에만 부여합니다. 이 한 가지 사실이 혼란의 대부분을 설명합니다. 같은 계정이 파일 서버에서는 성공하고 DC에서는 실패하기 때문입니다. 거부 권한은 그룹 구성원 자격과 무관하게 해당 허용 권한을 이깁니다. 따라서 허용과 거부를 모두 가진 계정은 거부됩니다. 넓은 거부 그룹은 호의로 추가된 관리자까지 잡을 수 있습니다.

로컬 대화 상자가 아니라 적용되는 정책을 읽어라

로컬 정책은 같은 권한을 정의하는 모든 도메인 GPO에 의해 덮어써지므로, 로컬 스냅인은 올바르게 보이는 목록을 표시하면서 실제 적용 상태는 다를 수 있습니다. 컴퓨터가 실제로 적용하는 내용을 내보낸 다음 권한을 찾아 표시 이름 대신 SID를 읽으십시오:

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

그 출력에서 *S-1-5-32-544은 Administrators이고 *S-1-5-32-555은 Remote Desktop Users입니다.

둘 다 나타나지 않으면 로컬 사용자 및 그룹 대화 상자가 무엇을 제안하든 정책 보유자 외에는 아무도 데스크톱을 열 수 없습니다. 그러면 gpresult이 이긴 GPO를 지목하며, 그것이 편집해야 할 개체입니다. 도메인 가입 컴퓨터에서 로컬 정책을 바꾸는 것은 테스트이지 해결이 아닙니다.

맞는 가장 좁은 권한을 부여하라

일반적인 답은 대상의 Remote Desktop Users 그룹입니다. 기본적으로 권한을 가지며 Administrators보다 훨씬 작고, «데스크톱을 열 수 있음»과 «서버를 관리할 수 있음»을 분리합니다. 정책이 권한을 명시적으로 재할당한 곳에서는 아무도 액세스 제어로 의도하지 않은 그룹을 추가하는 대신 해당 그룹이나 계정을 그 정책에 추가하십시오.

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

무엇이든 추가하기 전에 거부 목록을 확인하십시오. 거부 권한이 사용자를 포함하는 그룹을 지목하면 올바른 변경은 해당 그룹에서 계정을 제거하거나 거부를 좁히는 것이지 다른 곳에 두 번째 허용을 추가하는 것이 아닙니다. 어떤 권한을 어디서 바꿨는지 기록하십시오. 나중에 GPO 새로 고침이 이전 상태를 조용히 복원하고 티켓이 같은 메시지로 다시 열립니다.

네트워크 경로는 별도 결정으로 유지하라

VPN 그룹이 모든 포트에 도달할 필요는 없습니다. 그룹이 데스크톱이 아니라 애플리케이션을 필요로 할 때, 터널 풀과 애플리케이션 포트로 범위가 한정된 방화벽 규칙이 그 정책을 실행합니다. 로그온 권한은 그대로 둡니다.

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

OpenVPN 자체의 클라이언트별 구성과 Access Server 그룹 권한도 같은 취지로 대상 접두사를 제한할 수 있습니다. 어느 것도 Windows 로그온 권한을 부여하지 않으며, 로그온 권한이 포트를 열 수도 없습니다. 별도의 변경 창에서 다루십시오. 포트 규칙과 권한은 다른 사람이 승인하기 때문입니다.

관문이 적용되는 같은 순서로 확인하십시오. 계정이 터널을 만들 수 있는지, 세션이 수신기에 도달하는지, 클라이언트가 인증하는지, 계정에 권한이 있는지입니다. 포트 테스트가 성공하는데 ping이 실패하면 ICMP에 다르게 응답하는 방화벽이지 RDP가 차단되었다는 증거가 아닙니다. Microsoft의 로그온 권한 참조에는 컴퓨터 역할별 기본값과 거부가 허용을 이긴다는 규칙이 나와 있습니다.