自分のPCにリモートで接続しようと腰を下ろし、資格情報を入力したのに、これ以上ないくらい不親切なかたちで「ユーザーアカウントの制限（たとえば時間帯の制限）によりログオンできません」と告げられる―これほど気が滅入ることはそうそうない。

時間帯の制限？このマシンは自分でセットアップしたのに。

それが私だった。ドメイン機能レベルを新しいものへ移行してから1時間後、Windows Server のマシンから締め出されてしまった。Microsoft のドキュメントやシステム管理者向けフォーラムを読み進め、最終的に何が問題だったのかをつなぎ合わせて理解したが、それはエラーメッセージが示唆するものとはまったく違っていた。

最初に誰も教えてくれないのはこの点だ。このエラーは単一の問題ではなく、カテゴリーである。原因は、パスワードなしのアカウントから、Kerberos のみが許可されているのに認証経路が密かに NTLM にフォールバックしてしまうケースまで、何でもあり得る。それが分かれば、解決は半分終わったも同然だ。

症状 / 原因	環境	最初の対処	発生頻度
ローカルアカウントのパスワードが空/未設定	スタンドアロン / ホームPC	対処1 — パスワードを設定する	よくある
RDP ログオンを許可するユーザー権利にアカウントがない	いずれでも	対処2 — ユーザー権利の割り当てを確認する	よくある
RDP ログオンを拒否するユーザー権利にアカウントが含まれている	いずれでも	対処2 — 拒否ポリシーから削除する	よくある
IP で接続しており、NTLM が制限されている	ドメイン	対処3 — FQDN ホスト名を使用する	よくある
アカウントがロックアウトされている	いずれでも	対処4 — ADUC / lusrmgr でロック解除する	時々発生
ログオン時間の制限	ドメイン	対処4 — ADUC でログオン時間を確認する	時々発生
Protected Users に属しており、Kerberos が機能しない	ドメイン	対処5 — Kerberos を修復するか、グループから削除する	管理/堅牢化
イベントログに認証失敗が表示される	いずれでも	対処6 — セキュリティログを確認する（イベント 4625）	診断

必要な修正は、あなたの環境に完全に依存します。何かに手を付ける前に、以下の質問をひととおり確認してください。

同じアカウントでローカルにログインできますか？ はいで、RDP だけが失敗する場合、資格情報の誤りが原因ではありません。問題は RDP の権限割り当て、ポリシーによる制限、または認証経路の問題です。対象マシンのイベントビューアー → Windows ログ → セキュリティで、イベント ID 4625 を確認してください。ドメイン環境の場合、一部の認証失敗はドメインコントローラーのセキュリティログでしか確認できないため、そちらも確認してください。

1人のユーザーか、全員か？ 単一ユーザーのロックアウトは、アカウントレベルの設定を示します。全員が同時にロックアウトされる場合は、最近のポリシー変更、グループポリシーの更新、またはサーバー側の構成変更が疑われます。

スタンドアロンマシンか、ドメイン参加か？ ドメイン環境では、Active Directory のグループポリシー、Kerberos、NTLM の制限、Protected Users の動作などが影響します。家庭用のスタンドアロン PC であれば、Fix 1、2、4 のみが関係する可能性が高いです。ドメイン環境であれば、すべての修正が該当する可能性があります。

IP アドレスで接続していますか、それともホスト名ですか？ これは多くの人が思う以上に重要です。IP アドレスで接続すると、通常 Windows は Kerberos を使用できず、NTLM へのフォールバックを強制されます。環境で NTLM が制限されている場合、そのフォールバックは失敗し、実際のアカウントに何の変更もなくても、まさにこのエラーが発生します。Fix 3 を参照してください。

最近何か変更がありましたか？ グループポリシーの更新、OS パッチ、ドメイン機能レベルのアップグレード、セキュリティの強化などが、目に見える警告なしに一晩で RDP を壊すことがあります。問題が自分のアカウントにあると決めつける前に、必ずこの点を確認してください。

ここで最も関連性が高いのは修正 1–4 です。これらには Active Directory やドメインに関する知識は不要です。

ここから始めてください。特に自宅のPCやスタンドアロンマシンで。

Windows は既定で、パスワードのないローカルアカウントによるリモートログオンをブロックします。これは意図的で、文書化されたセキュリティポリシーです。”Accounts: Limit local account use of blank passwords to console logon only” 設定は既定で有効になっており、つまりパスワード未設定のアカウントは対話型コンソールログオンに制限されます。RDP はリモートの対話型ログオンであるため、ブロックされます。

なぜこれが起こるのか: Microsoft は、この動作をローカルセキュリティポリシー設定「アカウント: 空のパスワードのローカルアカウントの使用をコンソールログオンのみに制限する」で文書化しています。(Microsoft Learn)

パスワードを設定します：コンピューターの管理を開く → ローカルユーザーとグループ → ユーザー → アカウントを右クリック → パスワードの設定。これで解決する場合は、完了です。

回避策があります：secpol.msc またはレジストリキー LimitBlankPasswordUse を使用して、空のパスワードの制限を無効にできます。ネットワークにアクセス可能なマシンでは、最後の手段として扱ってください。

警告: 空のパスワードの制限を無効化すると、攻撃面が大幅に弱体化します。強力なパスワードを設定することが常に正しい解決策です。

これは最も一般的な原因の一つであり、見落としやすいものの一つです。

Windows は RDP アクセスを制御するために、補完的な 2 つのグループポリシー設定を使用します:

リモートデスクトップサービスを介したログオンを許可する — 接続する権限を付与します。
リモートデスクトップサービスを介したログオンを拒否する — 接続する権限をブロックします。

グループメンバーシップに関係なく、拒否ポリシーは常に許可より優先されます。これは Microsoft によって文書化されている動作です。

入手場所: gpedit.msc を開き、コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカルポリシー → ユーザー権利の割り当て。

両方のポリシーを確認してください。あなたのアカウント、またはそれが所属するグループ（たとえば Remote Desktop Users や Administrators）が「許可」に表示されていることを確認してください。拒否」に表示されていないことも確認してください。アカウントが「許可」にまったく含まれていない場合、パスワードや資格情報に関係なく、RDP へのアクセスはブロックされます。

ドメインに参加しているマシンでは: これらの権限はグループポリシーによってドメインレベルで設定でき、ローカル設定を上書きすることがあります。ローカル設定が正しいように見えても問題が解消しない場合は、対象コンピューターで gpresult /h report.html を使用して競合する GPO がないか確認してください。

このたった一つの変更で、不釣り合いなほど多くの問題が解決します。

IP アドレス（例: 192.168.1.100）で接続すると、Windows は通常 Kerberos 認証を使用できず、代わりに NTLM へフォールバックします。スタンドアロンの家庭用マシンではたいてい問題ありませんが、NTLM が制限または無効化されているドメイン参加マシンでは、このフォールバックはサイレントに失敗し、アカウント自体は何も変わっていないのにアカウント制限エラーが発生します。

代わりに、そのマシンのホスト名を使用してください:

server.yourdomain.com ✔ 推奨

192.168.1.100 ✘ NTLM へのフォールバックを強制

また、ドメイン参加マシンへ接続する際は、DOMAIN\user ではなく user@domain.com のような UPN 形式の資格情報を使用してください。これにより Windows が正しい認証経路を選択でき、驚くほど多くの例外的なケースを回避できます。

例外: Microsoft は、Windows Server 環境向けのより新しい Kerberos-over-IP 機能について記載していますが、明示的な構成が必要であり、既定では有効になっていません。 (Microsoft Learn: IP アドレス用の Kerberos の構成).

Windows は、複数の異なる制限タイプに対して同じ汎用メッセージを返します。これは、このエラーを非常に厄介なものにしている要因の一つです。アカウントのロックアウトとログオン時間の制限は、エラーメッセージが文字どおり正確であるという数少ないケースのうちの 2 つです。

ローカルアカウント（スタンドアロンまたはドメイン）の場合 lusrmgr.msc を開く → ユーザーを選択 → 「アカウントはロックアウトされています」にチェックが付いているか確認します。付いていれば解除します。

ドメインアカウントの場合 Active Directory ユーザーとコンピューターを開く → ユーザーを見つける → ダブルクリック → アカウントタブ。アカウントのロック解除にチェックを入れ、ログオン時間を確認します。

ある Windows Server 2016 の管理者はまさにこの壁に突き当たったと述べています。サーバーへの接続はアカウント制限のメッセージで失敗しましたが、時間制限は意図的に設定されていませんでした。原因は、ドメインポリシーの更新後にグループポリシーが知らないうちにログオン制限を適用していたことでした。セキュリティログのイベント ID 4625 に特定のサブコードが表示されていたはずです。

イベント 4625: 失敗したログオンのセキュリティログエントリには、正確な理由を特定するサブステータスコードが含まれます。一般的な値: 0xC0000234（アカウントがロックされています）0xC000006F（許可された時間外のログオン）0xC0000022（アクセス拒否）原因を推測する前にこれを確認してください。

修正5および6には、Active Directory へのアクセスと、Kerberos および NTLM に関する知識が必要です。スタンドアロンの家庭用PCを使用している場合は、このセクションをスキップして構いません。

これは、経験豊富な管理者を不意打ちする障害モードであり、多くの場合、ドメインのアップグレード後に発生します。

Active Directory の Protected Users セキュリティグループは、メンバーに対してより厳格な認証ルールを強制します:

NTLM 認証は完全にブロックされます。
Kerberos のみが許可され、しかも AES 暗号化に限られます。
RC4 および DES の Kerberos 暗号化方式は許可されません。
資格情報はコンピューター上にキャッシュされません。

机上では、これは極めて優れたセキュリティ対策です。実際には、NTL に暗黙に依存していた環境では RDP アクセスが機能しなくなります。これは、IP アドレスで接続した場合、DNS が誤って構成されている場合、またはドメインのアップグレード後に Kerberos が完全に検証されていない場合にまさに起こることです。ユーザーには、Protected Users が関与していることを示す手掛かりのない一般的なアカウント制限メッセージが表示されます。

なぜドメインのアップグレード後に表面化するのか: ドメイン機能レベルを引き上げると、既存のポリシーがより厳格に適用されるようになることがよくあります。すでに「保護されたユーザー」に含まれていたアカウントでも、以前は許容されていたNTLMへのフォールバックが突然失敗する場合があります。 (Microsoft Learn: 保護されたユーザーセキュリティグループ)

Protected Users から誰かを削除する前に、次の手順をこの順序で試してください：

IP アドレスではなく、そのマシンの FQDN（server.domain.com）を使用します。
UPN 資格情報（user@domain.com）を使用します。
接続元のマシンから DNS 解決が正しく機能することを確認します。
ドメインコントローラーへの接続性と、Kerberos サービスが実行中であることを確認します。

Kerberos が正常に動作している場合、アカウントに変更を加えなくても問題はたいてい解消されます。そうでない場合は、一時的な対処として、アカウントを Protected Users から削除できます：

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

PowerShell リモーティングについて: このアプローチは、PowerShell リモート処理が利用可能な場合に機能します。PowerShell リモート処理は、利用可能な場合は Kerberos を使用し、フォールバックとして NTLM を使用することにも注意してください。そのため、完全にハードニングされた環境では同様の認証上の制限に直面する可能性があります。 (Microsoft Learn: WinRM セキュリティ)

警告: アカウントを「保護されたユーザー」から削除すると、セキュリティの堅牢性が低下します。これは恒久的な修正ではなく、診断のための手順として扱ってください。正しい解決策は、Kerberos がお使いの環境で正しく機能するようにすることです。

グループメンバーシップの変更後に RDP を再試行する前に、サインアウトし、認証の更新が反映されるのを待ってください。

この時点で推測はやめ、ログを読みましょう。

対象マシン上 Event Viewer → Windows Logs → Security。Event ID 4625 でフィルターします。各エントリには Failure Reason と Sub Status コードが含まれており、RDP のエラーメッセージそのものよりもはるかに正確に原因を特定できます。

より深い認証トレースのために、Applications and Services Logs → Microsoft → Windows → Authentication も有効化します。

ドメインコントローラー上 一部の認証失敗、特に Kerberos 関連のものは、対象マシンではなくリクエストを処理したドメインコントローラーにのみ記録されます。ローカルの対象ログだけでは全体像がつかめない場合は、DC の Security ログを確認してください。

Event 4625 の Sub Status コードが分かれば、エラーは曖昧なものではなく、特定して診断できる具体的な問題になります。一般的なコードは上記の Fix 4 の注記に記載されています。

エラーコード 0xC07 が表示される場合、特に macOS で Microsoft Remote Desktop を使用しているときに、本記事で説明している認証や制限に関する同種の問題と併せて現れることが一般的です。コミュニティの報告によれば、IP アドレスではなくホスト名で接続すると多くの場合に解決し、これは Fix 3 で説明した NTLM フォールバックのパターンと一致します。

0xC07 を単一の根本原因に明確に対応付ける決定的な Microsoft のドキュメントはありません。これを正確な診断ではなく、問題のカテゴリが正しいことを示すシグナルとして扱ってください。上記の対処法が適用されます。

RDP アクセスが「user account restriction」というメッセージとともに拒否された場合、Windows は想定どおりに動作しています。ただし、どの規則に引っかかったのかは教えてくれません。

最短で解決する方法は次のとおりです:

この記事の冒頭にある診断マトリクスを使って、最も可能性の高い原因を特定します。
お使いの環境（ホーム/スタンドアロンまたはドメイン）に該当する修正を適用します。
原因が不明な場合は、対象マシンのイベント ID 4625 を確認します。
ドメイン環境では、アカウント設定を変更する前に、ドメインコントローラーのログも確認し、Kerberos が機能していることを確認します。

たいていは単純な問題です。そうでない場合でも、多くは論理的に説明のつくものですが、非常に不親切なメッセージの裏に隠れているだけです。

ユーザーアカウントの制限が原因でログオンできない場合の修正方法

クイック診断

第1部: 家庭用PC & スタンドアロンマシン

対処法 1: アカウントにパスワードが設定されていない

対処法 2: RDP を介して接続できるユーザーを確認する

対処法3: IPアドレスでの接続をやめる

対処法 4: アカウントのロックアウトおよびログオン時間の制限を確認する

パート2: ドメインおよびエンタープライズ環境

対処法 5: 保護されたユーザーグループ

対処法6: 他に説明がつかないときはログを確認する

エラーコード 0xC07 については？

概要

ユーザー アカウントの制限が原因でログオンできない場合の修正方法