新しいWindows 11ノートで社内共有をマップしようとすると、指紋認証後に資格情報を何度も求められ、最終的に「System error 1920（The file cannot be accessed by the system）」で失敗――この症状は、SMBではなくWebDAV（WebClient）が前に出てしまうことや、Azure AD参加のみの端末での認証条件が合わないことが主因です。原因を切り分けつつ、確実に成功させる実務手順をまとめました。
想定する環境と症状
- 新規導入の Windows 11 ノートPC（オンプレAD未参加、Azure AD 参加のみ）。
- 社内サーバーの共有フォルダーを「ネットワーク ドライブに割り当て」で接続しようとすると、
認証UI → 資格情報を3回要求 → System error 1920。その後、error 67（ネットワーク名が見つかりません）、error 53（ネットワーク パスが見つかりません）が混在して発生。 pingとTCP 445は到達。既存のマップ済みドライブ・資格情報は削除済み。ネットワーク プロファイルは「プライベート」。dsregcmd /statusで Azure AD 参加のみを確認。
結論（最短で復旧させる要点）
- WebDAV リダイレクター（WebClient サービス）を停止・無効化：SMBではなくWebDAVに振られる誤判定を回避。
- SMBを明示し、ドメイン資格情報で割り当て：
net useで UNC とDOMAIN\ユーザー名を指定。 - 名前解決と経路を再点検：FQDNのUNC、DNSキャッシュのクリア、SMB-Inの許可。
- Azure AD 参加端末の認証条件を満たす：オンプレAD未参加なら Kerberosは使えないため、サーバー側のNTLM許可 or Azure AD Kerberos（クラウド トラスト等）or ハイブリッド参加を検討。
症状別エラー早見表
| エラー | メッセージ | 起きやすい要因 | 一次対処 |
|---|---|---|---|
| 1920 | The file cannot be accessed by the system | WebClient（WebDAV）が優先され、SMBでなくHTTP系に誤誘導 | WebClientを停止・無効化し、SMBで再試行 |
| 67 | ネットワーク名が見つかりません | 名前解決ミス、UNCの表記誤り、サフィックス不足 | FQDNのUNCで接続、DNSキャッシュクリア |
| 53 | ネットワーク パスが見つかりません | 経路/ファイアウォール、SMBポート遮断、共有名誤り | TCP 445到達確認、SMB-In許可、共有名を再確認 |
なぜ起きるのか（背景とメカニズム）
SMB と WebDAV の優先順位
通常、\\SERVER\Share という UNCパス はSMBで解決されます。しかし、クライアントの状態やシェルの解決過程によっては、WebDAVのリダイレクター（WebClient）がフックされ、HTTP/HTTPS系のドライブ マップとして扱おうとして失敗するケースがあります。これが System error 1920 を誘発する典型例です。
Azure AD 参加端末とSMB認証
オンプレADに参加していない Azure AD 参加（AADJ） 端末は、ドメイン資格情報での Kerberos SSO が成立しません。サーバー側がNTLM拒否や制限を行っていると、資格情報を3回求められた末に失敗します。対策は、（1）サーバー側でNTLMの許可・緩和、（2）Azure AD Kerberos（クラウド トラスト 等） を整備してKerberosを利用、（3）端末をハイブリッドAzure AD参加/ドメイン参加とし、通常のKerberosに戻す、のいずれかです。
解決手順（実務レシピ）
WebDAV リダイレクター（WebClient）を停止・無効化
まずはWebClientを止め、起動種別を無効（または手動）にします。scコマンドの start= の後に半角空白が必要です。
sc stop WebClient
sc config WebClient start= disabled
レジストリで行う場合：
reg add "HKLM\SYSTEM\CurrentControlSet\Services\WebClient" /v Start /t REG_DWORD /d 4 /f
変更後は再起動が確実です。再起動できない事情があっても、多くは上記だけで効果が出ます。
SMB を明示してドライブを割り当て
管理者のコマンド プロンプト（またはPowerShell）で、UNCとドメイン資格情報を明確に指定します。UNCはバックスラッシュ2本です。
net use Z: \\SERVER\Share /user:DOMAIN\ユーザー名 /persistent:no
FQDN（例：\\filesvr.contoso.local\Share）を用いると、名前解決の揺らぎに強くなります。PowerShellを使うなら：
$cred = Get-Credential # DOMAIN\ユーザー名 で入力
New-PSDrive -Name Z -PSProvider FileSystem -Root \\filesvr.contoso.local\Share -Credential $cred -Persist
error 67/53 への対処（名前解決・経路）
- 名前解決の再評価：
ping SERVERとping SERVER.会社ドメインの差を見る。FQDNで接続。 - キャッシュの初期化：
ipconfig /flushdns nbtstat -R - 経路とポート：
Test-NetConnection -ComputerName filesvr.contoso.local -Port 445でTCP445を再確認。 - Windows ファイアウォール：「ファイルとプリンターの共有（SMB-In）」が有効か確認。
Get-NetFirewallRule -DisplayGroup "ファイルとプリンターの共有" | Where-Object Enabled -eq True - UNCの表記揺れ：
\\と/の混在、共有名の大文字小文字の勘違いを排除。
Azure AD 参加端末でSMB認証が通らない場合の選択肢
| 選択肢 | 概要 | 利点 | 留意点 |
|---|---|---|---|
| NTLM を許可 | サーバー側でNTLM制限を緩和し、DOMAIN\ユーザー名 + パスワードで認証 | 即効性が高い | セキュリティ方針と整合が必要。将来は段階的に無効化したい |
| Azure AD Kerberos（クラウド トラスト等） | Azure AD 参加端末からオンプレのKerberosを利用可能にする | パスワード入力なしのSSOに近づく | ドメインコントローラーとクライアントの要件/構成が必要 |
| ハイブリッドAzure AD参加／ドメイン参加 | 端末をオンプレADへ参加（またはハイブリッド） | 従来のKerberos/グルポ適用が可能 | 展開や運用負荷が増える |
NTLMの緩和を選ぶ場合は、「ネットワーク セキュリティ：NTLM制限」ポリシーや、SMBサーバー側の「NTLMを受け付ける/拒否する」設定範囲を点検してください。セキュリティ方針上、必要最小限に限定することが重要です。
確認・切り分けのための具体コマンド
| 目的 | 推奨コマンド | 期待される結果 |
|---|---|---|
| Azure AD 参加状態を確認 | dsregcmd /status | AzureAdJoined : YES、DomainJoined : NO など |
| TCP 445の到達確認 | Test-NetConnection filesvr.contoso.local -Port 445 | TcpTestSucceeded : True であれば到達 |
| DNSサフィックスの確認 | ipconfig /all | プライマリDNSサフィックス、検索リストが意図通り |
| SMBセッションの状態 | Get-SmbConnection | 方針や暗号化/署名の状態、接続先サーバーが確認できる |
| 資格情報の整理 | cmdkey /list、cmdkey /delete:ターゲット | 古い保存資格情報を排除 |
| Kerberosチケットの掃除 | klist purge | キャッシュの影響を排除（AADJ端末では基本NTLM想定） |
作業の全体像（まとめ表）
| 手順 | 内容 | 代表コマンド | ポイント |
|---|---|---|---|
| 1 | WebClient を停止・無効化 | sc stop WebClientsc config WebClient start= disabled | start= 後の半角空白に注意。レジストリなら Start=4 |
| 2 | SMBで割り当て | net use Z: \\SERVER\Share /user:DOMAIN\ユーザー名 /persistent:no | UNCは \\ から。FQDN推奨 |
| 3 | Error 67/53 を潰す | ipconfig /flushdnsnbtstat -R | DNSサフィックス・SMB-In許可も要確認 |
| 4 | Azure AD 参加端末の認証要件 | （設定項目・ポリシーの確認） | NTLM許可 or Azure AD Kerberos or ハイブリッド参加 |
| 5 | WebDAVが必要なら再有効化 | sc config WebClient start= demandsc start WebClient | SMB利用が安定してから戻す |
よくある落とし穴と回避策
- 管理者権限のコンソールで作ったマップがエクスプローラーに見えない：UACの二重トークンが原因。必要なら
EnableLinkedConnectionsを導入（運用ポリシーに従う）。 - IPで接続すると通るがホスト名だとNG：DNSサフィックス/検索リストの不足。FQDNで安定化、長期はDNSを是正。
- ゲスト共有に接続できない：Windows 11は既定でゲスト無効。どうしても必要なら「Lanman Workstation: Enable insecure guest logons」を最小範囲で許可。
- SMB 1.0 を有効にすれば直る？：安全上の理由で非推奨。Windows 11 と現行サーバーは SMB 2/3 を使うのが前提。
- SMB署名のポリシー：サーバー側「常に署名」やクライアント側の必須設定が厳しすぎると古いNAS等で失敗。署名/暗号の整合性を確認。
セキュリティ方針と実運用のベストプラクティス
- 資格情報の明示：AADJ端末では
DOMAIN\ユーザー名を常に明示。User Principal Name（user@domain）で通る環境でも、まずは前者で確認。 - NTLMの扱い：許可する場合は「対象サーバー／特定OU配下」など範囲を限定し、監査ログで可視化。
- Azure AD Kerberos/クラウド トラスト：段階的導入でパスワードレスSSOへ。パイロット端末→段階拡張が現実的。
- 命名規則：UNCはFQDNの統一を推奨。DNSサフィックスやWINSに依存しない運用へ。
- 再発防止：イメージ展開時点でWebClientの起動種類標準化、SMB・認証ポリシーのベースライン化。
チェックリスト（抜け漏れ防止用）
- WebClientが停止/無効になっている。
- UNCはFQDN（例：
\\filesvr.contoso.local\Share）。 - DNSキャッシュ初期化済み（
ipconfig /flushdns,nbtstat -R）。 - Windows ファイアウォールでSMB-In許可（必要なプロファイルに）。
- 資格情報マネージャーに古いエントリが残っていない（
cmdkey /listで確認）。 - サーバー側でNTLMを必要最小限許可、またはAzure AD Kerberos/クラウド トラストを構成。
- VPN/ゼロトラストのポリシーでTCP445が遮断されていない。
- 共有名・権限・事前アクセス許可（ACL）が適正。
トラブル時のログ着眼点
- イベント ビューアー：Microsoft-Windows-SMBClient、Security（ログオン種別3）を確認。NTLM拒否/Kerberos失敗などが痕跡に出ます。
- ネットワーク トレース：
pktmon start --etw -p 0で簡易取得、停止はpktmon stop。SMBネゴシエーションやリセットの有無をチェック。 - タイムスキュー：Kerberos利用時は時刻同期が必須。NTP/ADの同期状態を点検。
復旧後のメンテナンス（WebDAVを使う場合）
業務でWebDAVドライブが必要なら、SMB接続が安定した上で、必要な端末のみに限定して再有効化します。
sc config WebClient start= demand
sc start WebClient
WebDAVを使う際は、HTTP/HTTPSのプロキシや証明書、認証方式（基本認証/NTLM/ネゴシエート）の整合性も合わせて確認してください。
一括実行用のスクリプト例（管理者向け）
現場での切り戻しや再現テストを効率化するためのテンプレートです。テキストを .cmd で保存して管理者として実行します。
@echo off
rem --- Step 1: WebClient を停止・無効化
sc stop WebClient
sc config WebClient start= disabled
rem --- Step 2: DNSキャッシュの初期化
ipconfig /flushdns
nbtstat -R
rem --- Step 3: 既存のドライブと資格情報を整理（必要なら）
net use * /delete /y
for /f "tokens=2 delims=:" %%i in ('cmdkey /list ^| findstr /i "Target"') do cmdkey /delete:%%i
rem --- Step 4: SMBで再割り当て（要書き換え）
set SERVER=filesvr.contoso.local
set SHARE=Share
set USER=DOMAIN\user01
set /p PWD=Password for %USER% :
net use Z: \%SERVER%%SHARE% %PWD% /user:%USER% /persistent:no
rem --- Step 5: 動作確認
dir Z:
echo Done. まとめ
System error 1920 の多くは、SMBではなくWebDAVに流れてしまうことが起点です。まずは WebClientの停止/無効化 と SMBでの明示的な割り当て を実施し、残る error 67/53 は 名前解決・経路 の再点検で潰します。端末が Azure AD 参加のみ の場合は、サーバー側の NTLM許可、もしくは Azure AD Kerberos/クラウド トラスト の整備、さらに将来的には ハイブリッド参加 を含めて検討すると、再現性の高い安定運用に到達できます。
コメント