リモートデスクトップ権限なしの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のログオン権限のリファレンスには、マシンの役割ごとの既定値と、拒否が許可を上回る規則が記載されています。