Active Directory環境でUserLockのログオン時にOTPを入力した直後、”ClsdException”…と表示されログインできない場合は、端末がUserLockサーバーへ到達できない（VPN未接続・SMB/445遮断・DNS不良）など通信要因が多いです。本記事は最短復旧の手順と恒久対策を解説します。
UserLockでOTP入力後に認証エラーが出るときに起きていること
問い合わせでよく挙がる症状は、Windowsのサインイン画面でワンタイムパスワード（OTP）を入力した直後に、次のような例外メッセージが表示され、そのままログオンが失敗するケースです。
“ClsdException” caught, ID = 11(“(NULL)”), last error = 1398(“(NULL)”)
このタイプのエラーは、UserLockの認証（MFA/OTP）そのものが「必ず」壊れているというより、OTP入力後にUserLockエージェントがUserLockサーバーへ到達できず、ポリシー照合やMFA判定が完了しない状況で発生しやすいとされます。特に、端末が社内ネットワークに未接続（VPN未接続含む）である、あるいは必要な通信（ICMP/SMB等）が遮断されている場合は最優先で疑います。
最短で復旧させるためのチェックリスト
まずは「原因究明」より先に、現場で最短復旧につながりやすい確認順で潰していきます。下表の上から順にチェックすると、遠回りになりにくいです。
| 優先 | 確認ポイント | 具体的な確認方法 | ダメだった場合の方向性 |
|---|---|---|---|
| 高 | 社内ネットワーク/VPN接続 | VPNが接続済みか、社内DNSが引けるか | VPNのプリログオン対応、ネットワーク経路/DNSを修正 |
| 高 | UserLockサーバーに到達できる | ping、共有(\\server)、TCP445疎通 | FWでSMB(445)やICMPが遮断、名前解決不良を疑う |
| 中 | UserLockサービス稼働 | UserLockサーバーでサービス稼働、イベントログ確認 | サービス停止/異常、サーバー負荷、再起動やログ解析 |
| 中 | AD側の異常（ロックアウト等） | ロックアウト/無効/期限切れ、イベントID確認 | アカウント復旧、認証経路（DC/DNS）修正 |
| 中 | 端末時刻/サーバー時刻 | w32tm、スマホ時刻自動設定 | TOTP不一致の可能性、NTP/ドメイン時刻階層を整備 |
| 低 | 特定ユーザーのみ再現 | 別ユーザーで試す | ユーザーのMFA状態・所属グループ・ポリシー衝突の疑い |
通信の全体像を把握して切り分けを早くする
UserLockは、ログオン時に端末側（Desktop Agent / Credential Provider）がUserLockサーバーへ問い合わせ、サーバー側は必要に応じてActive Directory（DC/GC）やデータベース等と連携します。つまり、OTP入力後に失敗する場合でも、ボトルネックは「OTP」以外（ネットワーク、サーバー到達性、AD参照）であることが少なくありません。
特に重要なのが、UserLock Desktop AgentとUserLockサーバー間で必要になる通信です。公式ドキュメントでは、少なくともICMP（疎通確認）と、SMB（TCP 445）による通信が必要である旨が整理されています。
| 通信元 → 通信先 | 目的 | プロトコル/ポート例 | 詰まったときの典型症状 |
|---|---|---|---|
| 端末 → UserLockサーバー | ログオン可否判定、MFA/ポリシー照合 | ICMP、SMB TCP 445 | OTP後に例外、ログオン失敗 |
| UserLockサーバー → DC/GC | ユーザー認証、グループ参照 | LDAP TCP 389、GC TCP 3268、SMB TCP 445 | 認証遅延、ユーザー照合失敗 |
| UserLockサーバー ↔ 端末 | エージェント管理、リモート操作/状態確認 | SMB、Remote Registry、RPC等 | エージェント配布/状態確認が失敗 |
※環境の構成（バックアップサーバー、UserLock Anywhere、SQLの置き場所等）によって、必要な通信は増えます。通信要件の整理は「いま必要な範囲」に絞って考えるのがコツです。
原因で最も多い：端末が社内ネットワークにいない（VPN未接続含む）
このエラーに関しては、端末が社内ネットワークに接続できていない（VPNが切れている／ログオン前にVPNを張れない／社内DNSに到達できない）ケースがまず疑われます。Microsoft Q&Aの回答でも、当該エラーはUserLockサービスへの接続性に起因する可能性が示唆され、端末が社内ネットワークに接続されていない状況で発生し得るとされています。
疎通確認は「pingだけ」で終わらせない
pingが通っても、SMB（445）が塞がれていればUserLockの通信が成立しないことがあります。次の3点をセットで確認してください。
- 名前解決：FQDNでUserLockサーバーが引けるか（UserLockはFQDN利用が前提になりやすい）
- ICMP：UserLockサーバーにpingが届くか
- SMB：
\\UserLockServerFQDNが開けるか、TCP 445が到達できるか
# DNS/FQDN確認
nslookup userlockserver.example.local
# ICMP疎通
ping userlockserver.example.local
# SMB疎通（共有一覧が開けるか）
explorer \\userlockserver.example.local
# TCP 445疎通（PowerShell）
Test-NetConnection userlockserver.example.local -Port 445UserLockエージェントは、通信前にpingを行い、その後SMB（TCP 445）でUserLockサーバーと通信する流れが説明されています。したがって、VPN越し・拠点間越し・端末FW越しのいずれでも、TCP 445が通らない設計だとOTP入力後に失敗しやすい、という見立てが立ちます。
Windows Defender Firewall / 社内FWで塞がれやすいポイント
セキュリティ強化（ハードニング）で「ファイル共有は不要だから閉じる」としてSMBを塞いだ結果、UserLockの動作要件に当たってしまうのは現場でよくある落とし穴です。公式のガイドでは、UserLockサーバーと保護対象端末間の通信のために、Windows FirewallでFile and Printer Sharing（ICMP/SMB）関連のルールを有効化する手順が示されています。
| ルール例 | 方向 | 意図 | 実務のポイント |
|---|---|---|---|
| File and Printer Sharing (Echo Request – ICMPv4-In / ICMPv6-In) | 受信 | 疎通確認 | 「許可する送信元」をUserLockサーバーのIPに限定して安全性を上げる |
| File and Printer Sharing (SMB-In) | 受信 | SMB通信 | 445を全開放せず、サーバー↔端末の範囲だけ通す設計にする |
大規模環境では、端末ごとの手作業よりもGPO（グループポリシー）でFWルールを配布・統制したほうが「いつの間にか塞がっていた」を防げます。ガイドでもGPO配布が推奨されています。
リモート端末は「ログオン前にVPNが張れるか」が勝負
OTP入力が必要なログオンで失敗する端末がリモートワーク中心の場合、Windowsログオン画面の時点でVPNに接続できないことが原因になることがあります。UserLockの設定ガイドでは、LAN/VPNがない状況でもエージェントがUserLockサービスへ到達できる仕組み（UserLock Anywhere）や、ログオン画面からVPN接続できるようにする考え方が整理されています。
運用としては、次のいずれかの方針に寄せると安定します。
- プリログオンVPN（ログオン画面VPN）を採用：ログオン前に社内へ入れるようにする
- UserLock Anywhereの利用を検討：社内LAN/VPNに依存しにくい認証設計にする（クラウド/オンプレのモードがある）
特にUserLock Anywhereでは、端末が一度LAN/VPN経由でUserLockサービスに接触して“準備完了”状態になっていないと、リモート認証が成立しない端末が出る点が注意事項として説明されています。
UserLockサービスやエージェントの状態を確認する
UserLockコンソールで「エージェントが生きているか」を見る
端末側の問題か、サーバー側の問題かを分ける最短ルートは、「UserLockコンソールで当該端末が活動（セッション）として見えているか」を確認することです。公式の“Verify your setup”では、アクティブセッションが見えない場合にエージェント側の問題の可能性を示し、端末ダッシュボードからエージェント状態を確認する手順が案内されています。
- UserLockコンソール → Environment ▸ Machines
- 対象端末を選択 → Actions → Check the agent status
端末側のサービス（ULAgentService）の確認
UserLock Desktop Agentには「UserLock agent service（ULAgentService）」が含まれることが明記されています。端末側でこのサービスが停止している、もしくは破損していると、ログオンフローに影響が出る可能性があります。
# 端末で実行（管理者）
Get-Service -Name ULAgentService -ErrorAction SilentlyContinue
# 見つからない/停止なら、インストール状態やサービス起動を確認公式のリモートアクセステストで「必要条件」を一気に洗い出す
「pingは通るのに直らない」「端末が多くて個別に追えない」場合は、公式ガイドにある“通信要件の実地テスト”が強力です。ここで躓く箇所が、そのまま原因候補になります。
| テスト | どこで実施 | 目的 | 失敗時に疑うこと |
|---|---|---|---|
explorer \\COMPUTERFQDN\ADMIN$ | UserLockサーバー（サービスの偽装/impersonationアカウントで） | admin$共有＋権限＋SMB疎通 | SMB遮断、権限不足、admin$無効 |
| リモートレジストリ接続（regedit → Connect Network Registry） | UserLockサーバー | Remote Registry / RPC疎通 | Remote Registry停止、RPC遮断、FW |
UlTermの REMOTEACCESSTEST | UserLockコンソール | 詳細診断 | 出力をそのまま保全し、設計/ルールを修正 |
UlAgentExe.exe /REMOTEACCESSTEST | 端末側 | エージェント目線の通信診断 | 端末FW、名前解決、VPN経路 |
また、要件として「保護対象端末でRemote Registryサービスが有効・起動していること」や、「admin$共有が無効化されている場合のレジストリ設定（AutoShareWks/AutoShareServer）」が挙げられています。端末側でこれらが無効化されていると、エージェント管理や診断が詰まり、復旧が遅れやすくなります。
Active Directory側の確認：ロックアウトやDC到達性を潰す
OTP入力後に失敗して見えても、裏ではAD側の制御（ロックアウト、無効化、期限切れ、DC到達不可）が絡んでいることがあります。特に、VPN越しでDNSが不安定だと「UserLockには届くがDCに届かない」などの歪な状態になりやすいので、ADの基本チェックも同時に実施します。
アカウントロックアウトの確認（PowerShell）
# 管理端末/サーバーで実行（RSAT/ADモジュールが必要）
Get-ADUser -Identity <ユーザー名> -Properties LockedOut | Select-Object LockedOut
# 併用すると一覧確認に便利
Search-ADAccount -LockedOut | Select-Object Name,SamAccountNameイベントログで「何が拒否したか」を見える化する
原因切り分けでは、端末・UserLockサーバー・DCのイベントログを“同じ時刻帯”で突き合わせるのが効果的です。最低限、次のイベントを押さえておくと会話が早くなります。
| ログ | 代表的なイベントID | 見るべき内容 |
|---|---|---|
| Windowsログ > セキュリティ（DC） | 4740 | アカウントロックアウト発生の有無 |
| Windowsログ > セキュリティ（端末/サーバー） | 4625 | ログオン失敗の理由（ユーザー名/ログオン種別/失敗理由） |
| Windowsログ > アプリケーション（UserLockサーバー） | （環境依存） | UserLock関連エラー、サービス停止、通信失敗 |
ポイントは、「OTPを打った瞬間」に端末側で何が起き、サーバー/DC側で何が起きたかを時系列で並べることです。ログを取らずに対症療法だけを繰り返すと、再発時にまたゼロからになります。
OTP（ワンタイムパスワード）の落とし穴：時刻ずれとオフライン動作
TOTP系のOTPは時刻に依存するため、スマホの時刻ずれ・端末時刻ずれ・サーバー時刻ずれが大きいと失敗します。特に在宅端末で「手動で時刻を変えていた」「休止復帰後に時計がずれた」「NTPが社内に向かず同期できていない」などが重なると、入力自体は正しくても判定が通りません。
スマホ側：自動時刻を有効化する
- スマホの「日付と時刻」設定を自動にする
- タイムゾーンも自動にする（海外出張・VPN利用時のズレ対策）
Windows端末/サーバー側：時刻同期を確認する
# 状態確認
w32tm /query /status
# 同期の再実行（権限が必要）
w32tm /resync加えて、UserLock側には「社内ネットワークに接続できずUserLockサービスへ到達できないログオン（Logons without UserLock connection）」に対する動作方針が用意されています。つまり、オフライン/到達不可時に、常に許可するのか、MFAを求めるのか、拒否するのかを設計できます。リモートワークが前提の組織では、この設定が曖昧だと“ある日突然ログオンできない”が起きやすいです。
| 設定方針 | 挙動のイメージ | 向いている環境 |
|---|---|---|
| Always allow logins | 到達不可でもログオン自体は通る | オフライン作業が多く、可用性優先 |
| Ask for MFA / Force MFA | 条件によりMFA要求、満たせない場合は拒否 | 在宅でもMFAを維持したいが運用は柔軟にしたい |
| Always deny logins | 到達不可なら必ず拒否 | 機密端末・ゼロトラスト寄りで“社外は許可しない”方針 |
なお、Windowsにはドメインコントローラーが利用できない場合でもキャッシュ資格情報でログオンできる仕組みがあり、これはUserLockとは独立した挙動になり得ます。オフライン時の許容/拒否は、UserLock側の設計とWindows側の仕様の両方を踏まえて決める必要があります。
切り分けのコツ：別ユーザー・別端末で再現性を取る
「この端末だけ？このユーザーだけ？」を早めに切り分けると、調査の当たりが付けやすくなります。
| 再現パターン | 疑う順番 | 次の一手 |
|---|---|---|
| すべてのユーザーで同じ端末だけ失敗 | 端末のFW/ネットワーク/VPN、エージェント | TCP445疎通、エージェント状態、REMOTEACCESSTEST |
| 特定ユーザーだけ複数端末で失敗 | ユーザーのMFA状態、ポリシー衝突、ロックアウト | ADロックアウト確認、UserLockポリシー適用状況確認 |
| 社外（在宅/出張）だけ失敗 | プリログオンVPN、UserLock Anywhere、DNS | ログオン画面VPN、UserLock Anywhere設計へ |
再発防止：運用と設計で“たまに失敗”をなくす
ファイアウォールルールはGPOで統制し、範囲はIPで絞る
「一度直ったのに再発する」は、端末のFWプロファイル変更、別のセキュリティ製品、ベースライン適用、Windowsアップデート後の設定戻りなどで起きます。公式ガイドの通り、GPOで必要ルールを配布し、ScopeでUserLockサーバーと端末の範囲に絞ると、セキュリティと可用性のバランスが取りやすくなります。
リモートワーク前提ならUserLock Anywhereを検討する
「社内にいないと動かない」設計のままリモートワークを増やすと、VPN・回線品質・拠点FWの影響を受け続けます。UserLockは、LAN/VPNがない状況でもエージェントがUserLockサービスへ到達できる仕組み（UserLock Anywhere）を提供しており、一般設定にも項目として整理されています。要件や端末の“Cloud-ready”条件もあるため、導入前に対象端末の状態を洗い出すのが重要です。
障害時のエスカレーション用に「取るべき情報」をテンプレ化する
ベンダー/社内運用へエスカレーションする際に、次の情報が揃っていると解決までの往復が減ります。
- 発生日時（タイムゾーン含む）
- 対象ユーザー（SamAccountName）
- 対象端末名（FQDN/NetBIOS）
- 端末が社内/VPN/社外のどこにいたか
ping、Test-NetConnection -Port 445の結果- UserLockコンソールのエージェントステータス結果
- REMOTEACCESSTESTの出力（可能なら）
- イベントログ（4740/4625/UserLock関連）の該当時刻帯
よくある質問
SMB（445）を開けるのが不安です。回避できますか？
UserLock Desktop Agentは、UserLockサーバーとの通信にSMB（TCP 445）を用いる旨が公式ドキュメントに説明されています。従って「完全に閉じたまま」での安定運用は難しく、代替策としては開放範囲をIPで絞る、拠点間はVPN/専用線で閉域にする、社外はUserLock Anywhereへ寄せる、といった設計が現実的です。
エラー表示そのものをユーザーに見せたくありません
UserLockには、エージェントとサーバーの通信問題（ネットワーク障害やサーバー問題）でログオン/ログオフ時に出るエラーを非表示にする設定が用意されています。ユーザー体験の改善には有効ですが、根本原因（到達性やFW）は残るため、恒久対策とセットで使うのがおすすめです。
まとめ
“ClsdException”（ID=11 / last error=1398）でOTP入力後にログオンできない場合、最初に疑うべきは端末→UserLockサーバーの到達性です。特にリモートワークでは「VPNがログオン前に張れない」「SMB(445)が塞がっている」「DNS/FQDNで引けない」の3つが原因になりやすいです。次に、UserLockサービス/エージェントの状態、ADのロックアウトや到達性、時刻同期を順に潰していけば、原因へ最短で到達できます。公式のREMOTEACCESSTESTやエージェントステータス確認を併用し、再発しない“運用設計”まで落とし込むのがゴールです。
コメント