Windows Server 2016（1607 / OS build 14393.4046）で、普段は接続できる RDP がある時点から突然ログオンできなくなり、TerminalServices-LocalSessionManager に Event ID 36（0xD00002FE）が大量に出る――。この現象を素早く復旧しつつ、原因を絞るための切り分け手順を実務目線でまとめます。
症状の整理：どこまで進んで、どこで失敗しているのか
今回のポイントは、RDP の接続が「認証」だけで完結しているわけではなく、複数段階の処理で成り立っていることです。ユーザー名/パスワード（または証明書）による認証が通っても、その後のセッション生成（LocalSessionManager）やユーザープロファイルの読み込み、シェル起動で失敗すれば「ログオンできない」状態になります。
| ログ（チャネル） | Event ID | 代表的な表示 | 読み取りのコツ |
|---|---|---|---|
| Microsoft-Windows-TerminalServices-LocalSessionManager/Operational | 36 | An error occurred when transitioning from Initialized in response to EvCreated. (ErrorCode 0xD00002FE) | セッション状態の遷移（作成/初期化）でエラー。資格情報の正誤というより「セッションが作れない」側に寄る。 |
| Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational | 1149 | Remote Desktop Services: User authentication succeeded | 「認証成功」と表示されるが、環境によっては説明が紛らわしいケースもあるため、確定判断は Security ログ（4624/4625）と突合する。 |
| Windows Logs / Security | 4624 / 4625 | ログオン成功 / 失敗 | RDP なら Logon Type 10（RemoteInteractive）や 3（ネットワーク）などを確認。時刻を合わせて相関を見る。 |
| Windows Logs / System（Schannel） | 36874 など | TLS/証明書/暗号スイート関連の失敗 | TLS 層で問題がある場合に手掛かりが出る。暗号/セキュリティ層の切り分けと相性が良い。 |
今回の現象では、RemoteConnectionManager 側に 1149 が出ている一方で LocalSessionManager 側が Event ID 36 を大量に吐いて落ちているため、体感としては「認証は進むのに、肝心のセッションが作れない」状態に見えます。Microsoft Q&A の同条件（Windows Server 2016 / 14393.4046 / Event ID 36 / 0xD00002FE）でも、まずはサービス再起動→FIPS→セキュリティ層の順で切り分ける提案がされています。
まず試すべき「切り分け 3 点」
この手の RDP 障害は、原因追及に時間をかけるほど復旧が遅れがちです。まずは「復旧しやすい・副作用が把握しやすい」順に、最短で当たりを付けます。下の表は、現場でそのまま運用しやすい形に整理したものです。
| 切り分け | 狙い | 期待する変化 | 注意点 | 戻し方 |
|---|---|---|---|---|
| Remote Desktop Services の再起動 | 詰まり/リーク/内部状態の破綻をいったんリセット | 一時復旧することが多い | 既存セッション切断の可能性。RDP が唯一の経路だと詰むことがある | 不要（元設定に戻す概念なし） |
| FIPS 準拠アルゴリズム強制ポリシーを無効化（検証） | TLS/暗号スイートの縛りによる不整合を除外 | 再発が止まる/発生頻度が下がる | コンプライアンス影響の確認が必要 | 元の GPO 状態へ戻す |
| セキュリティ層を RDP Security Layer に固定（検証） | TLS/Schannel/証明書まわりを迂回して影響範囲を絞る | つながるなら TLS 側が怪しい | NLA が使えないため恒久策には不向き | Negotiate / SSL(TLS) へ戻し、NLA を有効に戻す |
Remote Desktop Services を再起動して復旧するか確認
Microsoft Q&A でも最初の切り分けとして挙げられている通り、まずは Remote Desktop Services（TermService）を再起動して、現象が一時的にでも収束するかを確認します。
サーバーの役割が RD セッション ホスト（いわゆるターミナルサーバー）だと、TermService の再起動は影響が大きいので注意してください。可能なら保守時間帯、またはコンソール接続（iLO/iDRAC、Hyper-V コンソール、Azure のシリアルコンソール等）を確保してから実施します。
PowerShell（管理者）例：
Restart-Service -Name TermService -Forceサービス名が分からない場合の確認：
Get-Service *TermService*,*UmRdpService*,*SessionEnv* | Format-Table -Autoここで「再起動すると直るが、しばらくすると再発する」のであれば、根本原因は残っています。ただし重要な収穫があり、ネットワークや資格情報というより、RDS コンポーネント内部の状態や暗号設定の不整合を疑う優先度が上がります。
FIPS 準拠アルゴリズム強制ポリシーを無効化して再発有無を確認
次に、暗号まわりの縛り（FIPS）が原因に絡んでいないかを切り分けます。具体的には、次のポリシーを無効化（または「未構成」）にして様子を見ます。
設定場所（GPO / ローカル セキュリティ ポリシー）：
コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → セキュリティ オプション →
「システム暗号化: 暗号化、ハッシュ化、署名に FIPS 準拠アルゴリズムを使用する」
この設定は、Microsoft のセキュリティ ポリシー解説でも、TLS/SSL の提供者（プロバイダー）が FIPS 準拠の強力な暗号スイート（例：TLS_RSA_WITH_3DES_EDE_CBC_SHA）に制限される旨が説明されており、RDS（Remote Desktop Services）のネットワーク通信暗号にも影響することが明記されています。
つまり、環境によっては次のような「方針の衝突」が起きやすくなります。
- セキュリティベースラインや暗号強化で 3DES を無効化している
- 一方で FIPS 強制により、RDS 側が 3DES 前提の挙動に寄ってしまう
- その結果、クライアントとサーバーで「使える暗号」の共通部分がなくなり、RDP が不安定/失敗する
なお、Microsoft の FIPS 140 バリデーション解説では「FIPS mode はアルゴリズム選択を制御するものではない」点も説明されており、コンプライアンス要件の解釈と技術的な副作用が噛み合わないことがあります。セキュリティ担当/監査要件とセットで扱うのが安全です。
現場でのおすすめ運用：
- まずは検証環境または限定 OUで無効化し、再発が止まるかを見る
- 止まる場合は、FIPS を恒久的に外すのか、暗号ポリシー（3DES を含む/含まない）を見直すのかを整理する
- 止まらない場合は、暗号以外（セッション/プロファイル/リソース）へ疑いを移す
RDP のセキュリティ層を「RDP Security Layer」に固定して再発有無を確認
3つ目は、RDP のセキュリティ層を固定して、TLS（Schannel）周りを疑うべきかどうかを切り分けます。Microsoft Q&A の当該事例でも「RDP Security Layer に設定して確認」が提案されています。
設定場所（GPO）：
リモート デスクトップ サービス → リモート デスクトップ セッション ホスト → セキュリティ →
「RDP 接続に特定のセキュリティ層の使用を要求する」 を有効にして、RDP Security Layer を選択
ここで必ず押さえたい注意点があります。Microsoft の解説では、RDP Security Layer を選ぶと Network Level Authentication（NLA）は使用できないとされています。つまり、検証目的なら有効ですが、恒久策として置き換えるとセキュリティ姿勢が変わります。
検証としての読み方：
- RDP Security Layer にすると安定する → TLS/証明書/暗号スイートの不整合が本命（Schannel/暗号強化/証明書更新などを重点確認）
- 変わらない → セッション作成自体（LSM、プロファイル、リソース枯渇、RDS 内部状態）を疑う
また、管理画面や GPO の表示で「SSL (TLS 1.0)」と出ても、実際には TLS 1.2 を使っているケースがあり、表示自体が GUI バグである可能性が Microsoft のトラブルシューティングに記載されています。表示だけを根拠に「TLS 1.0 を使っている」と断定しないのが安全です。
なぜ「1149 が出ているのに入れない」のか
1149 は RemoteConnectionManager 側のイベントで、表示上は「User authentication succeeded」となります。一方で、セッション生成（LocalSessionManager）や、ユーザープロファイル読み込み、Explorer 起動などは別コンポーネントの責務です。つまり、1149 が出ていても、その後段で失敗すればユーザー視点では「入れない」になります。
さらに、1149 の解釈には注意が必要です。解析用途の資料では「成功ログとして扱われがち」な一方で、「説明が紛らわしく、失敗時にも出ることがある」とされるケースも報告されています。したがって、障害解析では Security ログ（4624/4625）や LSM 側のイベントとセットで相関させるのが確実です。
イベントログで原因を絞るためのチェックリスト
Event ID 36 自体はメッセージが抽象的で、単体で「原因がこれ」と断定しにくいタイプです。そこで、同時刻に出ている周辺ログを揃えて「どの段階で失敗しているか」を特定します。
| 確認対象 | 見る場所 | 確認ポイント | 次のアクション |
|---|---|---|---|
| RDP 接続の到達 | RemoteConnectionManager/Operational（1149 など） | 接続が来ているか、発生頻度、発生時刻 | 同時刻の LSM（36）と突合 |
| セッション生成の成否 | LocalSessionManager/Operational（36/21/22 など） | 36 の直前/直後に他のエラーがないか | ユーザープロファイル/ディスク/リソースへ展開 |
| 本当に認証は成功しているか | Security（4624/4625） | 対象ユーザー/Logon Type/失敗理由 | 資格情報/アカウントロック/ポリシーも排除 |
| TLS/暗号/証明書の失敗 | System（Schannel）＋ RDP 関連 Operational ログ | 握手失敗、証明書失効、暗号スイート不一致 | FIPS/暗号強化/証明書更新/セキュリティ層設定を見直す |
| リソース枯渇の兆候 | System / Application / パフォーマンス | メモリ不足、ハンドル枯渇、プロファイルサービス異常、ディスク逼迫 | 再発時刻のメトリクス（RAM/CPU/ディスク/ハンドル）を採取 |
再発した瞬間にやっておくと効くこと：
- イベントログを退避（EVTX で保存）し、後から相関しやすくする
- 適用されている GPO を保存（後から「その時の暗号設定」を再現できる）
ログ退避例：
wevtutil epl "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" C:\Temp\TS_LSM_Operational.evtx
wevtutil epl "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" C:\Temp\TS_RCM_Operational.evtx
wevtutil epl "System" C:\Temp\System.evtx
wevtutil epl "Security" C:\Temp\Security.evtxGPO の保存例：
gpresult /h C:\Temp\gpresult.html暗号設定が原因だった場合の「現場で刺さる」考え方
FIPS とセキュリティ層の切り分けで改善した場合、次は「なぜその状態になったのか」を潰すフェーズです。よくあるのは、次のどれか（または複合）です。
- セキュリティ強化（暗号スイート/プロトコル制限）を入れたが、RDP が必要とする暗号との整合が崩れた
- OS 更新やミドルウェア更新で、使用できる暗号の組み合わせが変わった
- 証明書（RDS 用のサーバー証明書）が更新/失効/ストア不整合を起こし、TLS 層が不安定になった
特に FIPS は、Microsoft のセキュリティポリシー解説で RDS の暗号（3DES）の話が出てくるほど影響範囲が広く、暗号制限の方針と衝突しやすい設定です。
恒久対策の方向性（おすすめの順）：
- まずは Windows Update を最新化し、RDS/Schannel まわりの既知不具合を踏みにくくする
- 「SSL (TLS) を使う（Negotiate / SSL）」を前提に、証明書と暗号設定を整合させる
- コンプライアンス要件として FIPS が必要なら、“FIPS を有効にすること”が要件なのか、“FIPS 140 検証済みモジュールを使うこと”が要件なのかを整理し、運用と技術の落とし所を作る
暗号設定で改善しない場合に疑うべきポイント
切り分け 3 点をやっても再発する場合、次は「セッション生成に失敗する理由」をシステム要因から潰していきます。Event ID 36 は“結果”として出ているだけで、トリガーは別の場所にあることも珍しくありません。
| 疑うカテゴリ | ありがちな原因 | 現象 | 最短で当たりを付ける方法 |
|---|---|---|---|
| リソース/枯渇 | メモリ不足、ハンドル枯渇、ディスク逼迫、ページファイル不足 | しばらく稼働後に急に発生、再起動/サービス再起動で一時復旧 | 再発時刻のメトリクス採取、イベントログ（System/Application）で不足系を確認 |
| ユーザープロファイル | プロファイル破損、漫然とした肥大化、AV/EDR の干渉、プロファイルサービス異常 | 特定ユーザーだけ失敗/あるユーザーが起点で全体が重くなる | 別ユーザーでログオンできるか、Application ログの User Profile Service を確認 |
| RDS の内部状態 | TermService 依存関係、ポートリダイレクタ不具合、セッション管理の詰まり | 1149 が出るのに入れない、再起動で戻る | サービス再起動で復旧するか、LSM/RCM ログを時刻相関で見る |
ここまで来ると、現場的には「障害発生時に確実に証拠が取れる仕組み」が最重要になります。再発が不定期ならなおさらです。ログの自動退避（タスクスケジューラ＋wevtutil）や、監視で「RDP ログオン失敗のスパイク」と「サーバーリソース」を同時に取れるようにすると、原因に近づく速度が上がります。
暫定回避と恒久対策を両立する運用のコツ
最後に、同様の障害が出たときに“詰まない”ための運用メモです。
- RDP 以外の管理経路を必ず用意（仮想基盤コンソール、アウトオブバンド、踏み台、緊急用ローカルアカウントなど）
- 暫定回避（TermService 再起動）をする前に、ログを退避する手順を決めておく
- FIPS や暗号設定は、適用範囲を絞って段階的に（OU/セキュリティグループ/検証サーバー）
- セキュリティ層の固定（RDP Security Layer）は検証用のレバーとして使い、恒久策は「TLS を使った上で整合させる」方向に戻す
参考情報（一次情報）
- Microsoft Q&A：Windows Server 2016（14393.4046）で Event ID 36（0xD00002FE）発生時の切り分け提案
- Microsoft Learn（Security policy setting）：FIPS 準拠アルゴリズム強制ポリシーの影響（TLS/SSL、RDS での 3DES など）
- Microsoft Q&A：RDP の Security Layer と、RDP Security Layer 選択時に NLA が使えない点
- Microsoft Learn（Troubleshooting）：RDP の Security Layer 表示（SSL/TLS 1.0 表記）が実際の TLS バージョンを反映しないことがある
- Event ID 1149 の解釈に関する注意（説明が紛らわしいケースがある）
コメント