Windows 11アップグレード後に「ドメインが利用できないため、この資格情報ではサインインできません」が発生した話

Windows 10 から Windows 11 へ更新した AD 参加端末で、ネットワークに接続していないとログインできない事象が発生しました。

表示されたメッセージは以下です。

ドメインが利用できないため、この資格情報ではサインインできません。デバイスが組織のネットワークに接続されていることを確認し、やり直してください。このデバイスで、別の資格情報を使用して最近ログインした場合は、その資格情報を使ってログオンすることができます。

通常、AD 環境の Windows 端末では、一度ドメインユーザーでログインしていれば、ドメインコントローラーに接続できない状態でもキャッシュされた資格情報でログインできます。

ところが今回の端末では、ネットワークに接続している時はログインできるのに、LAN ケーブルを抜いた状態、または社内ネットワークに接続していない状態ではログインできませんでした。

先に結論

原因は、ProfileList に残っていた対象ユーザーの SID.bak と State=0x8000 でした。

対象キーは以下です。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

対象ユーザーの SID に .bak が付いており、さらに State が 0x8000 になっていました。

修正した内容は以下です。

• 対象SIDの .bak を外す
• State を 0 に戻す
• RefCount があれば 0 に戻す

この修正後、オフライン状態でもログインできるようになり、イベントビューアーで イベントID 4624 / ログオンタイプ 11 を確認できました。

Winlogon の自動ログオン設定も確認しましたが、今回の根本原因ではありませんでした。

発生した環境

今回の環境は以下です。

ポイントは，Windows 10 時代から使っていたドメインユーザーで発生したことです。

一方で，Windows 10 時代には一度もサインインしていなかった別のドメイン管理者アカウントでは，Windows 11 上で初回サインイン後，オフラインログオンできました。

この違いから，端末全体のキャッシュログオン設定ではなく，特定ユーザーのプロファイル異常を疑う流れになりました。

発生した症状

Windows 11 更新後，対象の AD ユーザーで以下の症状が出ました。

• 社内ネットワーク接続中はログインできる
• ネットワーク未接続だとログインできない
• CachedLogonsCount は 10
• ドメインとの信頼関係は正常
• 別のドメイン管理者アカウントではオフラインログオンできる
• 対象ユーザーだけオフラインログオンできない
• プロファイルを削除しても「アカウントにサインインできません」が出る

この時点で，単純な「キャッシュされていないだけ」ではありません。

最初に確認したこと

ADキャッシュログオン設定(CachedLogonsCount)の確認

最初に疑ったのは，ADキャッシュログオンの設定です。キャッシュログオンが無効化されていないか確認しました。

コマンドプロンプト or ターミナルを起動し，以下のコマンドを実行します。

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount

今回の端末では，結果は以下でした。

「0」ではなかったため，キャッシュログオンが無効化されているわけではなく，
今回は 10 なので，通常であれば直近 10 ユーザー分のドメインログオン情報がキャッシュされます。
つまり，CachedLogonsCount は原因ではありませんでした。

ドメインとの信頼関係を確認

次に、端末とドメインの信頼関係を確認しました。

管理者のコマンドプロンプトで以下を実行します。

nltest /sc_verify:DOMAIN-NAME

管理者で実行していないとエラーが出ます。

I_NetLogonControl を実行できませんでした: Status = 5 0x5 ERROR_ACCESS_DENIED

今回の端末では、ドメインコントローラーとの信頼関係は正常でした。

そのため、以下は原因ではないと判断しました。

CachedLogonsCount が無効になっている

ドメイン参加が壊れている

端末とドメインの信頼関係が壊れている

ドメインコントローラーへ接続できていない

1度もログインしていないキャッシュされていないユーザーでログイン

ADサーバーに接続している状態で，新規ユーザーを作成して，ログイン。
ようこそが表示され，プロファイルが作成されたことを確認しました。。

この状態で，オフラインにして，ログインすると問題なくログインできました。

ユーザープロファイルをリネームしてログイン

「C:\Users\ 」にある対象ユーザーのプロファイルフォルダを old にリネームして新規プロファイルを作ろうとしても
「アカウントにサインインできません」エラーが出ました。

しかし、再度サインインしても以下の画面が表示されました。

アカウントにサインインできません
この問題は、アカウントからサインアウトし、もう一度サインインすると解決できることがよくあります。

サインアウトしても改善しません。

この時点で、C:\Users\ユーザー名 側だけではなく、ProfileList 側のレジストリ情報が壊れている可能性が高くなりました。

レジストリから ProfileList の SID.bak と State を確認する

ここからは、対象ユーザーのプロファイル情報をレジストリから確認します。

確認する場所は以下です。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

ProfileList 配下には、ユーザープロファイルごとの SID が並んでいます。

S-1-5-18
S-1-5-19
S-1-5-20
S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx
S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx.bak

対象ユーザーの SID を特定するには、各 SID キーを開き、右側にある ProfileImagePath を確認します。

さらに、対象 SID キーの中にある State を確認します。

今回の端末では、State の値が 0x00008000になっていました。

10進数表示では32768です。

この状態では、Windows が対象ユーザーのプロファイルを正常なプロファイルとして扱えていない可能性があります。

そのため、ネットワーク接続時はログインできても、ネットワーク未接続時のキャッシュログオンが正常に動作しない状態になっていたと判断しました。

今回確認できた異常は以下の2点です。

• 対象ユーザーの SID に .bak が付いていた
• State が 0x00008000 になっていた

このため、次の手順で対象 SID の .bak を外し、State を 0 に戻してプロファイル情報を修正しました。

SID.bak とは何か

ProfileList 配下の SID に .bak が付いている場合、Windows がそのユーザープロファイルを正常に読み込めず、退避状態として扱っている可能性があります。

典型的な流れは以下です。

• 既存プロファイルを読み込もうとする
• 何らかの理由で読み込みに失敗
• Windows が元の SID キーを .bak として退避
• 別の一時プロファイルまたは仮状態でログオンしようとする
• 「アカウントにサインインできません」が出る

今回のように Windows 10 から Windows 11 へ更新した端末では、既存プロファイルの引き継ぎ時にこの状態になることがあります。

【推奨】レジストリ操作の前はバックアップ

レジストリを修正する前に、必ずバックアップを取得します。

対象は以下です。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

コマンドでバックアップする場合は、以下です。

reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" "%USERPROFILE%\Desktop\ProfileList_backup.reg"

対象ユーザーの SID が分かっている場合は、SID 単位でバックアップしても構いません。

reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1411.bak" "%USERPROFILE%\Desktop\target_profile_backup.reg"

レジストリエディターから操作する場合は、対象キーを右クリックして エクスポート を選びます。

レジストリ操作を間違えると、対象ユーザーだけでなく別ユーザーのログオンにも影響します。

または，レジストリエディターで以下の操作をします。

• 対象キーを右クリック
• エクスポート
• .regファイルとして保存

問題が起きた場合は，エクスポートした .reg ファイルを戻せます。

修正手順

今回実施した修正は以下です。

STEP

管理者アカウントでログインする

対象ユーザーではなく、別の管理者アカウントでログインします。
対象ユーザーでログイン中の場合は、必ずサインアウトします。

STEP

ProfileList を開く

レジストリエディターで以下を開きます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

STEP

対象ユーザーの SID を探す

ProfileImagePathに対象ユーザーのパスが表示されます。

例：

C:\Users\fukurowl

対象ユーザーの SID に .bak が付いていることを確認します。

STEP

.bak を外す

対象 SID のキー名から .bak を外します。

修正前：S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1411.bak

修正後：S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1411

同じ SID で .bak なしのキーが別に存在する場合は注意が必要です。

状態	対応
.bak 付きだけ存在	.bak を外す
.bak 付きと .bak なしが両方存在	.bak なし側が一時プロファイルの可能性あり。 バックアップ後に内容を確認して整理
どれが対象か不明	ProfileImagePath で判断

ここを誤ると、別ユーザーのプロファイルを壊します。

STEP

State を 0 に変更する

対象 SID キーの中にある State を確認します。

これを 0 に変更します。

RefCount が存在する場合は、こちらも 0 にします。

RefCount = 0

STEP

再起動する

レジストリ修正後、端末を再起動します。

再起動後、ネットワークに接続した状態で対象ユーザーでサインインします。

正常にプロファイルが読み込まれれば、次回以降のオフラインログオン確認に進みます。

設定後のオフラインログインできたか確認する

設定後にログインできたかどうかだけでは不十分です。

本当にキャッシュログオンで入れているかは，イベントビューアーで確認します。

確認場所

イベントビューアーを開き，Windows ログ，セキュリティの順に開きます。

確認するイベント ID は4624のログオン成功イベントです。

対象イベントを見つけたら，確認する項目は以下です。

ログオンタイプを確認し， 11になっていれば，オフライン認証できています。

おまけ：ログオンタイプ

ログオンタイプの主な意味は以下です。

今回は。修正後にイベント ID 4624 で ログオンタイプ: 11 を確認できました。

これで，AD ドメインコントローラーへ接続できない状態でも，キャッシュされた資格情報でログオンできたことになります。

今回の原因

今回の原因は，Winlogon 配下の自動ログオン設定ではなく，ProfileList に残っていた対象ユーザーのプロファイル情報異常でした。

確認した場所は以下です。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

対象ユーザーの SID を確認したところ，SID の末尾に .bak が付いたキーが存在していました。

さらに，そのキーの中にある State の値が 0x8000 になっていました。

10進数では 32768 です。

この状態では，Windows が対象ユーザーのプロファイルを正常なプロファイルとして扱えていない可能性があります。

実際，GUI からユーザープロファイルを削除したり，C:\Users\対象ユーザー のフォルダをリネームしても，「アカウントにサインインできません」という画面が表示され，正常にプロファイルを再作成できませんでした。

今回実施した修正は以下です。

• 対象SIDの .bak を外す
• State を 0 に戻す
• RefCount が存在する場合は 0 に戻す

修正後，ネットワーク接続状態で対象ユーザーにログインし直したところ，プロファイルが正常に読み込まれるようになりました。

その後，LANケーブルを抜いた状態でもログインできることを確認しました。

さらに，イベントビューアーのセキュリティログで イベント ID 4624 を確認したところ，ログオンタイプ: 11 が記録されていました。

ログオンタイプ 11 は，キャッシュされた資格情報によるログオンを意味します。

つまり今回の事象は，ADキャッシュログオンそのものが無効だったのではなく，対象ユーザーのプロファイル情報が ProfileList 上で異常な状態になっていたことで，オフラインログオンが正常に機能していなかったと判断できます。

なお，Winlogon 配下の DefaultUserName や DefaultDomainName などの自動ログオン系レジストリ値も確認しましたが，今回の根本原因ではありませんでした。

FAQ

CachedLogonsCountが10でもログインできないことはありますか？

あります。

CachedLogonsCount はキャッシュログオンの保存数に関する設定です。
ログオン画面側で別の認証処理に流れている場合、キャッシュが存在していてもログインできないことがあります。

SID.bak がある場合は削除すればいいですか？

いきなり削除するのは危険です。

まず、ProfileImagePath を確認して対象ユーザーの SID か判断します。

そのうえで、レジストリをバックアップし、.bak を外すリネームを行います。

同じ SID の .bak なしキーが別にある場合は、一時プロファイル側の可能性があるため、内容確認が必要です。

State=0x8000 は何を意味しますか？

少なくとも今回の端末では、対象ユーザーのプロファイルが正常状態ではないことを示す目印になっていました。

SID.bak と State=0x8000 が同時に存在していたため、Windows が対象プロファイルを正常に読み込めていない状態と判断しました。

オフラインログオン成功はどこで確認できますか？

イベントビューアーを開き，Windows ログ，セキュリティの順に開きます。

確認するイベント ID は4624のログオン成功イベントです。

対象イベントを見つけたら，確認する項目は以下です。

ログオンタイプを確認し， 11になっていれば，キャッシュされた資格情報によるログオンです。

Winlogon の DefaultUserName や AutoAdminLogon は確認不要ですか？

不要ではありません。

ただし、今回の主原因ではありません。

CachedLogonsCount や ProfileList が正常なのにログオン挙動がおかしい場合は、補助的に以下を確認する価値があります。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

• DefaultUserName
• DefaultDomainName
• DefaultPassword
• AutoAdminLogon
• ForceAutoLogon