Windows 11に更新後、AD端末がネットワーク未接続でログインできない原因はWinlogonの残骸だった

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

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

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

先に結論

結論から言うと，原因は以下のレジストリに残っていた自動ログオン系の値でした。

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

削除した値は以下です。

DefaultUserName
DefaultDomainName
DefaultPassword
AutoAdminLogon
ForceAutoLogon

特に今回の端末では，DefaultUserName と DefaultDomainName が残っていたことが問題でした。

次の章から，症状の詳細と確認した内容，修正した場所を解説します。

発生した症状

環境

OS：Windows 11
更新前：Windows 10
認証基盤：オンプレミスActive Directory
端末状態：ドメイン参加済み

症状

ネットワーク未接続状態でログインしようとすると，以下のメッセージが表示されログインできません。

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

ネットワークに接続している場合は，通常通りADユーザーでログインできます。

しかし，ネットワークを外すとログインできません。
ネットワーク接続時にはログインできるため，ADアカウント自体は有効です。
また，同じユーザーで過去にログイン実績もあるため，通常であればキャッシュログオンできるはずです。

確認したこと

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

最初に疑ったのは，ADキャッシュログオンの設定です。

コマンドプロンプト or ターミナルを起動し，以下のコマンドでレジストリを確認しました。

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

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

「0」ではなかったため，キャッシュログオンが無効化されているわけではありません。

ドメイン接続の確認

ネットワークを接続してログイン後に，ちゃんとドメインに接続されているかを確認しました。

コマンドプロンプト or ターミナルを起動し，以下のコマンドでレジストリを確認しました。

nltest /sc_verify:DOMAIN-NAME

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

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

今回の端末では結果は以下でした。
ドメインコントローラとの信頼関係は正常で，「ドメインに参加できていない」とか「信頼関係が壊れている」ケースではないことがわかりました。

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

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

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

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

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

レジストリから ProfileList の State を修正する

この作業をするためには，まず対象ユーザーのSIDを特定する必要があります。
ターミナルかコマンドプロンプトを開いて，以下のコマンドを実行します。

whoami /user

USER INFORMATION
----------------

ユーザー名      SID
=============== =============================================
DOMAIN\fukurowl S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX

あるいは，一つ前の作業でプロファイルが破損扱いになっていますので，レジストリエディターを開いて，以下の場所を開くと，対象のSIDの後ろに「.bak」が付いています。

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

あるいは，各キーを確認して，「ProfileImagePath」を見るとユーザー名が表示されています。

Stateを修正する

さて，本題ですが，対象のSIDが分かれば後は開いて，中の「State」を確認します。

今回の対象の場合は，値が8000になっていました。

bakは

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

レジストリを変更する前に，対象キーをエクスポートしておきます。

例：HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon の場合

reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" "%USERPROFILE%\Desktop\Winlogon_backup.reg"

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

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

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

以前の端末ではで直った

過去に似た事象が発生した端末では，以下のレジストリで State が 8000 になっていました。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>

その時は、以下の値に変更して解消しました。

State = 0

そのため、今回も同じ箇所を確認しました。

しかし、今回の端末では最初から以下の状態でした。

State = 0

さらに RefCount は存在しませんでした。

つまり今回は、ユーザープロファイルの読み込み状態だけが原因ではありません。

次に確認した場所

次に確認したのが、Winlogon配下の自動ログオン系レジストリです。

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

ここに、以下の値が残っていました。

DefaultUserName
DefaultDomainName
AutoAdminLogon

AutoAdminLogon は 0 でした。

一見すると、自動ログオンは無効に見えます。

しかし、DefaultUserName と DefaultDomainName が残っている状態でした。

この状態だと、Windowsのログオン画面が最後のユーザーや既定ユーザー情報を参照し、意図しないログオン処理に流れることがあります。

今回の端末では、この値を削除したところ、ネットワーク未接続でもログインできるようになりました。

実際に削除したレジストリ値

管理者権限でレジストリエディターを開き、以下の場所を開きます。

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

以下の値が存在する場合は、事前にバックアップを取ったうえで削除します。

DefaultUserName
DefaultDomainName
DefaultPassword
AutoAdminLogon
ForceAutoLogon

レジストリエディターで削除してもよいですが、コマンドで実行する場合は以下です。

reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultDomainName /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v ForceAutoLogon /f

削除後、端末を再起動します。

その後、ネットワークを切断した状態でADユーザーのパスワードログインを試します。

今回の端末では、これでネットワーク未接続でもログインできるようになりました。

注意点：自動ログオンを意図的に使っている端末では削除しない

以下のような端末では注意が必要です。

・キオスク端末
・サイネージ端末
・検査装置用端末
・自動起動アプリ専用端末
・共用端末で自動ログオンを意図的に使っている端末

これらの端末では、AutoAdminLogon や DefaultUserName が業務上必要な設定である可能性があります。

その場合は、削除前に運用設計を確認してください。

通常のAD参加PCで、自動ログオンを使っていない端末であれば、これらの値は残しておくメリットがほとんどありません。

切り分け手順まとめ

同じ事象が発生した場合は、以下の順番で確認します。

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

CachedLogonsCount

0  → キャッシュログオン無効
10 → 一般的な既定値

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>

State
RefCount
ProfileImagePath

State = 0
RefCount = 0 または存在しない
ProfileImagePath = 実在するユーザープロファイルパス

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

DefaultUserName
DefaultDomainName
DefaultPassword
AutoAdminLogon
ForceAutoLogon

今回の原因

今回の原因は，Winlogon配下に残っていた自動ログオン系のレジストリ値でした。

特に以下の値です。

DefaultUserName
DefaultDomainName

これらが残っていたことで、Windows 11のログオン処理が通常のADキャッシュログオンではなく、既定ユーザー情報を参照する流れに寄っていたと考えられます。

その結果、ネットワーク接続がある場合はログインできるのに、ネットワーク未接続時はログインできない状態になっていました。

削除後は、通常のログオン画面に戻り、キャッシュされたAD資格情報でログインできるようになりました。

再発防止

複数端末で同じ事象が出る場合は，個別端末の問題ではなく，以下のどれかが原因になっている可能性があります。

• Windows 10時代のマスターイメージ
• 初期セットアップスクリプト
• 過去に使った自動ログオン設定
• キッティング時の一時設定の消し忘れ
• GPOまたは管理ツールによるレジストリ投入

特に，キッティング時に一時的に自動ログオンを使った端末では，AutoAdminLogon=0 に戻していてもDefaultUserName や DefaultDomainName が残っている場合があります。

Windows 11移行後は，この残骸がログオン不具合として表面化することがあります。

結論

Windows 10からWindows 11へ更新したAD参加端末で、ネットワーク未接続時だけログインできない場合、まず以下を確認します。

• CachedLogonsCount
• ProfileList\<SID>\State
• WinlogonのDefaultUserName / DefaultDomainName
  

今回の端末ではProfileList の State は正常でした。

最終的に、以下の値を削除して解消しました。

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

DefaultUserName
DefaultDomainName
DefaultPassword
AutoAdminLogon
ForceAutoLogon

CachedLogonsCount が正常で、ProfileList の State も 0 なのにオフラインログオンできない場合は、Winlogon配下の自動ログオン残骸を確認する価値があります。

FAQ

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

あります。

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

ProfileListのStateが0なら正常ですか？

プロファイル状態としては正常寄りです。

ただし、今回のようにWinlogon側の値が原因の場合、State=0 でもログインできません。

AutoAdminLogonが0なら問題ありませんか？

必ずしもそうではありません。

AutoAdminLogon=0 でも、DefaultUserName や DefaultDomainName が残っていることがあります。
自動ログオンを使っていない端末では、関連する値をまとめて確認した方が安全です。

レジストリ削除後に再起動は必要ですか？

必要です。

ログオン処理に関わる値なので、削除後は再起動してから動作確認します。

会社の端末にそのまま適用してよいですか？

まずバックアップを取ってください。

また、自動ログオンを意図的に使っている端末では削除してはいけません。
通常のAD参加PCで、自動ログオンを使っていない端末に限定して確認するのが安全です。