Active Directory 管理者が突然 RDP できなくなったとき、原因が「Deny RDP access」グループへの追加だった——。この手のトラブルは“なぜ拒否されたか”の切り分けは比較的早い一方で、“誰がいつ追加したか”の特定は監査設定の有無で難易度が激変します。現場で使える確認手順と、再発防止の設計までまとめます。
まず押さえるべき結論：後追いで「誰が追加したか」を確定できるかは監査次第
今回のように、AD 管理者 3 名が「Deny RDP access」というセキュリティグループに追加され、それを外したら RDP できるようになったケースは、技術的には筋が通っています。
ただし、「誰が（いつ）その 3 名をグループへ追加したか」をイベントログで追えるかどうかは、事前に監査（Audit）を有効化していたかに依存します。監査が入っていなかった（またはログが上書きされて消えている）場合、後から Security ログだけで“犯人特定”まで到達するのは難しいことが多いです。
| 知りたいこと | 監査が事前に有効 | 監査が事前に無効 |
|---|---|---|
| 誰が追加したか（実行者） | DC の Security ログで追える可能性が高い | 原則として確定が困難（他ソース頼り） |
| いつ追加したか（時刻） | イベントのタイムスタンプで追える | whenChanged 等で近い時刻は出るが、操作ログではない |
| 誰がグループを作ったか | 作成イベントが残っていれば追える | 作成日時（whenCreated）は出るが作成者は確定できない |
なぜ「Deny RDP access」に入ると RDP できなくなるのか
多くの環境では、RDP ログオンの可否は「ユーザー権利の割り当て（User Rights Assignment）」で決まります。特に重要なのが、“許可（Allow）”より“拒否（Deny）”が優先される点です。
代表的な拒否設定は次のとおりです。
| 設定名 | 影響 | よくある指定先 |
|---|---|---|
| リモート デスクトップ サービスを通したログオンを拒否（Deny log on through Remote Desktop Services） | RDP（Logon Type 10）を拒否 | 「Deny RDP access」などのカスタム拒否グループ |
| ローカルでのログオンを拒否（Deny log on locally） | コンソール／仮想コンソール等の対話ログオンを拒否 | 制限対象ユーザーやサービス用アカウント |
| リモート デスクトップ サービスを通したログオンを許可（Allow log on through Remote Desktop Services） | RDP を許可する側の権利 | Administrators / Remote Desktop Users / 運用用グループ |
今回の症状は、GPO もしくはローカルポリシーの「拒否」に “Deny RDP access” グループが入っていたため、そのメンバー（＝AD 管理者 3 名）が RDP ログオン拒否された、という構図が典型です。
現場のコツ：「Administrators なのに RDP できない」場合、まず疑うべきは “Allow” ではなく “Deny” です。Deny 側に入っていたら、管理者権限でも普通に負けます。
最短で原因箇所を特定する：どのポリシーが拒否しているか
「Deny RDP access が効いている」ことが分かったら、次は“どこで拒否が定義されているか（どの GPO/ローカル設定か）”を突き止めます。ここを押さえると再発防止が一気にやりやすくなります。
サーバー側で結果（適用後の状態）を見る
- gpresult で適用されたポリシーを確認する
- rsop.msc（結果セットポリシー）で「ユーザー権利の割り当て」の結果を見る
- secpol.msc（ローカル セキュリティ ポリシー）でも最終状態を確認する
RDP 拒否の最終結果をチェックする手順例です。
gpresult /h C:\Temp\gpresult.html
start C:\Temp\gpresult.html確認する場所（どれも同じ方向を見ています）：
- コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → ローカル ポリシー → ユーザー権利の割り当て
- 「リモート デスクトップ サービスを通したログオンを拒否」
GPMC 側で“設定している場所”を見つける
サーバー上で結果を見たら、今度はGPO 側でその設定を入れている箇所を探します。運用で一番確実なのは次の 2 パターンです。
- GPMC の検索機能で GPO 全体から「Deny RDP access」や該当のユーザー権利を検索する
- PowerShell で全 GPO のレポートを出して文字列検索する（大規模環境で強い）
GPO レポートを XML で吐いて検索する例（管理用端末で実行）：
mkdir C:\Temp\GPO -Force
Get-GPO -All | ForEach-Object {
$name = $_.DisplayName -replace '[\\/:*?"<>|]', '_'
Get-GPOReport -Guid $_.Id -ReportType Xml -Path ("C:\Temp\GPO\{0}.xml" -f $name)
}
Select-String -Path C:\Temp\GPO*.xml -Pattern "Deny RDP access","SeDenyRemoteInteractiveLogonRight" -Listここでヒットした GPO が、拒否設定の“出どころ”候補になります。
「グループに入っていないのに拒否される」も要注意
AD グループはネスト（入れ子）されていることがあり、ユーザーが直接「Deny RDP access」に入っていなくても、上位グループ経由でメンバーになっている可能性があります。
ユーザーが（間接的に）どのグループに所属しているかを確認する例：
# ユーザーが所属しているグループ一覧（ネスト含む）
Get-ADPrincipalGroupMembership -Identity "user01" | Select-Object Name | Sort-Object Name「Deny RDP access」グループ自体のメンバーを再帰的に確認する例：
Get-ADGroupMember -Identity "Deny RDP access" -Recursive | Select-Object Name,SamAccountName,ObjectClass「誰が追加したか」を追跡する基本：見るべきログは“ドメイン コントローラー”
ドメイン環境で AD グループのメンバー追加・削除といった操作は、基本的にドメイン コントローラー（DC）の Security ログに記録されます。
- 操作が行われた DC（LDAP 書き込みを受けた DC）に記録されるのが原則
- 環境によっては運用上、特定の DC（例：PDC エミュレーター）に操作が集まりやすいが、決め打ちは危険
- 監査が無効、またはログ保持が短いと、痕跡が残らない
| ログの種類 | どこで見る？ | 分かること |
|---|---|---|
| Security（DC） | ドメイン コントローラー | グループ追加/削除、作成/削除の監査（有効なら） |
| Security（対象サーバー） | RDP 先のサーバー（AD サーバー） | RDP 失敗（4625）などの“結果”は出るが、誰がグループをいじったかは別問題 |
| Windows Event Forwarding / SIEM | 収集サーバー | DC のログが転送されていれば、保持期間が長く追跡しやすい |
監査を有効化して「次から確実に追える」状態を作る
結論として、同様の事象を確実に追えるようにするには、グループ管理の監査を有効化するのが王道です。ドメイン環境では、Domain Controllers OU にリンクした GPO で設定するのが一般的です。
有効化すべき代表的な監査（最低ライン）
少なくとも次は入れておくと、「誰が追加したか」を追う目的に直結します。
| 監査サブカテゴリ | 目的 | 推奨 |
|---|---|---|
| Security Group Management（セキュリティ グループ管理の監査） | セキュリティグループの作成/変更/メンバー追加削除 | 成功＋失敗 |
| Directory Service Changes（ディレクトリ サービスの変更の監査） | より詳細な変更監査（SACL 設定が必要） | 必要に応じて |
GPO の設定場所（Advanced Audit Policy を使う前提）：
- コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定
- 詳細監査ポリシーの構成 → 監査ポリシー → アカウント管理 → セキュリティ グループ管理の監査
また、環境によっては Advanced Audit Policy を確実に効かせるために、次のポリシーも合わせて確認します。
- セキュリティの設定 → ローカル ポリシー → セキュリティ オプション
- 「監査: 監査ポリシー サブカテゴリ設定を強制…」を有効
DC 上で監査が効いているかを確認する
設定後は DC 上で実際に有効になっているかを確認します。
auditpol /get /subcategory:"Security Group Management"「Success」「Failure」が有効になっていれば、少なくとも“記録される土台”は整っています。
イベントログで追跡する：追加・削除・作成で見るべきイベント ID
グループの種類（グローバル／ドメインローカル／ユニバーサル）により、メンバー追加・削除のイベント ID が分かれます。現場で迷いやすいので表で整理します。
メンバー追加・削除
| 用途 | グループの種類 | 追加 | 削除 | チェックのコツ |
|---|---|---|---|---|
| メンバー追加/削除 | Security-enabled Global Group | 4728 | 4729 | Target がグループ、Member が追加対象 |
| メンバー追加/削除 | Security-enabled Local Group（ドメイン ローカル含む） | 4732 | 4733 | “Deny 系”はドメインローカル運用が多い |
| メンバー追加/削除 | Security-enabled Universal Group | 4756 | 4757 | フォレスト跨ぎ/統合で使われることがある |
グループ作成・削除（「標準か？誰が作ったか？」を追う場合）
| 用途 | グループの種類 | 作成 | 削除 |
|---|---|---|---|
| グループ作成/削除 | Security-enabled Global Group | 4727 | 4730 |
| グループ作成/削除 | Security-enabled Local Group | 4731 | 4734 |
| グループ作成/削除 | Security-enabled Universal Group | 4754 | 4758 |
イベントの読み方：「誰が」「誰を」「どのグループに」追加したか
イベント ID（例：4732）を開くと、だいたい次の情報が取れます。ここを読めるようになると、追加者の特定が一気に現実的になります。
| 項目 | イベント内の呼び方（例） | 意味 | 今回の質問で重要度 |
|---|---|---|---|
| 実行者 | Subject | その操作を行ったアカウント（誰が追加したか） | 最重要 |
| 追加されたユーザー | Member | グループに追加（または削除）された対象 | 重要 |
| 対象グループ | Group / Target | 操作されたグループ名（Deny RDP access など） | 重要 |
| 発生元端末 | Caller Computer Name 等 | どの端末/サーバーから操作したかの手がかり | 状況次第で有用 |
たとえば、Security ログ上で「Deny RDP access」に関係するイベントだけを PowerShell で引くなら、次のような検索が現実的です（まずは 7 日など短い期間から）。
$ids = 4728,4729,4732,4733,4756,4757
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = $ids
StartTime = (Get-Date).AddDays(-7)
} | Where-Object {
$_.Message -match 'Deny RDP access'
} | Select-Object TimeCreated, Id, ProviderName, Message | Format-List「Message」をそのまま見ると長いので、運用ではイベント XML をパースして Subject/Member/Target だけ抜く形にすると事故りにくくなります。SIEM やログ収集基盤があるなら、同じ観点でフィールド抽出してアラート化するのが最強です。
「Deny RDP access」は標準（既定）グループなのか？
結論から言うと、“Deny RDP access” という名称のグループは Windows/AD の標準グループとして一般的に存在するものではありません。もちろん環境やテンプレート（硬化ガイド・ベンダー提供の運用設計）によっては作成され得ますが、少なくとも「デフォルトで必ずある」タイプではないため、誰か（または何か）が作った可能性が高いと考えるのが自然です。
“標準かどうか”を現場で判断するための観点です。
| 観点 | 確認方法 | 判断のヒント |
|---|---|---|
| 名前の規則 | 既定グループは英語名/日本語名が定番 | 組織独自っぽい命名（Deny RDP access 等）はカスタムの可能性が高い |
| 配置場所 | ADUC で OU/コンテナを確認 | Built-in/Users に無い、独自 OU にある場合はカスタム寄り |
| 説明・管理者 | description / managedBy を確認 | 運用目的やオーナーが書かれていれば設計グループの可能性 |
| SID/属性 | 既定グループは well-known SID に近い傾向 | 一般ユーザー作成の SID なら後天的に作られたと分かる（ただし“誰が”は別問題） |
「誰が作ったか」を調べたい：監査がない場合にできること／できないこと
グループの作成者を確定したい場合、監査が有効で作成イベント（4727/4731/4754）が残っていれば、そのイベントの Subject から追えます。
一方で、作成当時に監査が無効だった場合は、ADUC の属性から見える情報はせいぜい次の程度に留まります。
- whenCreated：作成日時
- whenChanged：最終変更日時（メンバー追加/削除でも更新され得る）
- description / info / adminDescription：運用メモが残っていれば目的の推測に役立つ
- managedBy：管理責任者（設定していれば有用。未設定なら空）
PowerShell で属性を見る例：
Get-ADGroup -Identity "Deny RDP access" -Properties whenCreated,whenChanged,managedBy,description,info |
Select-Object Name,whenCreated,whenChanged,managedBy,description,info重要：whenCreated は「いつ作られたか」の手がかりにはなりますが、作成者を証明するログではありません。“その時刻に作業していた人”を推測する材料にはなっても、監査ログの代わりにはならない点に注意が必要です。
監査が無かった（ログが見つからない）場合の現実的な追い方
「ログが無いなら終わり」になりがちですが、実務では“確定はできなくても、絞り込みはできる”ケースがあります。以下は現場で効く順に並べたアプローチです。
ログの所在を“DC ローカル”だけに限定しない
- Windows Event Forwarding（WEF）で DC の Security ログを収集していないか
- EDR/監視製品がイベントログを吸い上げていないか
- SIEM（Microsoft Sentinel、Splunk など）に転送されていないか
- バックアップ／スナップショットに DC のログが残っていないか（運用次第）
「いつ発生したか」を確度高く推定して、関係者と作業記録を突き合わせる
今回のケースでは「突然 RDP できなくなった」こと自体が強い手がかりです。
- RDP できなくなった最初の時刻を、対象サーバーの Security ログ（4625 の増加など）や運用チケットから拾う
- その時間帯に行われた変更作業（パッチ、GPO 変更、運用スクリプト）を洗い出す
- 定期ジョブ（タスクスケジューラ、運用バッチ、IdM/PAM）が関連していないか確認
SYSVOL・スクリプト・IaC の痕跡を探す
グループ操作が人手ではなくスクリプト経由だった場合、痕跡がソース側に残っていることがあります。
- ログオンスクリプト、運用 PowerShell、バッチに「Deny RDP access」という文字列がないか
- GPO のスクリプト（スタートアップ/シャットダウン）に該当処理がないか
- 構成管理（Ansible/DSC など）でローカル権利割り当てを配っていないか
RDP 拒否の“設計”を点検する：DC に直接 RDP させない運用へ
今回のトラブルが示しているのは、「特定グループに入るだけで AD 管理者でも DC に入れない」という強い統制が、意図せず発動してしまった可能性です。統制自体は悪ではありませんが、“意図した統制”として運用設計に落ちているかを点検する価値があります。
特にドメイン コントローラー（AD DS）に対しては、次のような運用が現場で安定します。
| 観点 | よくある問題 | おすすめの落としどころ |
|---|---|---|
| RDP 入口 | DC に直接 RDP しがち | 踏み台（ジャンプサーバー）経由に統一し、DC 直 RDP を最小化 |
| 許可/拒否の管理 | Deny グループが強すぎて事故る | Allow 側を明確化し、Deny は用途・条件を文書化（例：インシデント時の隔離用） |
| 変更統制 | グループ操作が誰でもできる／証跡がない | 監査＋ログ転送＋アラート（“Deny”グループ変更は即通知） |
| 責任の所在 | グループの目的が不明 | managedBy と description を必須にし、オーナー不在のグループを作らない |
再発防止の実装：最小構成で“次は必ず追える”にする
「監査を有効にする」だけだと、ログが DC に散在したり、上書きで消えたりして追跡が難しいままになりがちです。現実的には、次の 3 点セットで強度が上がります。
監査を有効化（グループ管理）
- DC に対して「Security Group Management（成功/失敗）」を有効化
- 監査の効き具合を auditpol で確認
ログの保持を確保（上書き対策）
- DC の Security ログサイズを適切に拡大
- 可能なら WEF/SIEM に転送して中長期保管
“Deny 系グループ”の変更をアラート化
狙いは単純で、「Deny RDP access のメンバーが変わったら即分かる」状態にすることです。監査イベントを収集できるなら、イベント ID（4728/4732/4756 等）＋ Target グループ名でアラートを組めます。
| アラート条件例 | 意図 | 運用メモ |
|---|---|---|
| 「Deny RDP access」へのメンバー追加 | 誤追加・隔離操作を即検知 | チケット番号/理由を description に残す運用とセットで |
| 「Deny RDP access」からのメンバー削除 | 意図しない解除を検知 | インシデント時に解除漏れも拾える |
| グループ自体の作成/削除 | 統制の土台が崩れるのを検知 | OU 単位で “Deny 系” を管理すると探しやすい |
すぐ使えるチェックリスト
最後に、今回のような「AD サーバーへ RDP できない／Deny グループが怪しい」事象で、現場が迷いにくい順番にまとめます。
| 手順 | やること | 目的 | ポイント |
|---|---|---|---|
| 切り分け | 対象ユーザーが「Deny RDP access」に入っていないか確認（ネスト含む） | 原因の特定 | ネストで見落としがち |
| 拒否の根拠 | サーバーで「Deny log on through Remote Desktop Services」を確認 | “どの権利で拒否か”を確定 | Deny は Allow より強い |
| 適用元 | gpresult/rsop で適用 GPO を確認 → GPMC で該当 GPO を特定 | 再発防止に繋げる | GPO 検索・全 GPO レポートが有効 |
| 追跡 | DC の Security ログで 4728/4732/4756 等を確認 | 誰が追加したか | 監査が無いと残らない |
| 恒久対策 | Security Group Management 監査を有効化＋ログ転送＋アラート化 | 次回は確実に追う | ログ保持（上書き対策）が重要 |
| 設計見直し | DC 直 RDP を減らし、踏み台運用と権利設計を整備 | 事故を起こしにくい構造へ | managedBy/description を運用必須に |
まとめ：今回の教訓は「監査を入れていないと、後からは強い証拠が残りにくい」
「Deny RDP access」グループに入っていたため RDP できなかった、という原因は比較的ストレートです。一方で、「誰がいつ追加したか」は、監査の有効化とログ保持が前提になります。今後のために、DC でのセキュリティ グループ管理の監査を有効化し、拒否設定（ユーザー権利の割り当て）と合わせて設計・運用を点検しておくことが、最も再現性の高い対策になります。
コメント