オンプレミスADをやめてPCをMicrosoft Entra参加（旧Azure AD参加）に切り替えたら、急にWindows 11同士で共有フォルダーや複合機のSMBスキャンが動かなくなった――そんなときの原因と「最短で復旧するための具体的な手順」をまとめました。ポリシーや設計の考え方にも触れながら、現場でそのまま使えるチェックリスト形式で解説します。
Entra参加PCでローカル共有フォルダーに接続できないのはなぜか
オンプレADを廃止して、PCをMicrosoft Entra（旧Azure AD）参加にした直後によく発生するのが、次のような症状です。
- Windows 11 Pro 間で作成した共有フォルダーに接続できない
- コンピューター名でもIPアドレスでも接続できない
- ping が通らない（応答なし）
- 共有自体は作成済みで、SMBも有効のはず
- 端末は同一ワークグループに所属
- 複合機のSMBスキャンも失敗する
この状況でよくある誤解は、「EntraアカウントでそのままSMB共有にSSOできるはず」という期待です。しかし、Entra参加PC同士のピア接続のSMBでは、Entra IDアカウントでのシングルサインオンは基本的に使えません。ドメイン参加時のようなKerberosベースのSSOは前提が異なります。
復旧のためのポイントは次の3つです。
- ネットワーク到達性とプロファイル（プライベート／パブリック）を正しく設定する
- ネットワーク探索とファイアウォール（SMB-Inなど）をきちんと許可する
- 共有側PCのローカルアカウントで認証させる設計に切り替える
これらを押さえれば、Entra参加環境でも従来と同じようにローカル共有を使い続けることができます。
まずは全体像をつかむ：症状と原因の関係
| 症状 | 典型的な原因 |
|---|---|
| ping も通らない | ネットワークプロファイルが「パブリック」、FirewallでICMP/445がブロック |
| ping は通るが共有にアクセス不可 | SMB-Inが無効、共有許可/NTFS権限不足、認証情報の指定ミス |
| 資格情報ダイアログが何度も出る | Entraアカウントで認証しようとしている、ローカルアカウントの指定方法が誤り |
| 複合機だけSMBスキャンに失敗 | 複合機がSMBv1前提・SMB署名非対応・古いファームウェア |
次から、最短で復旧させるための具体的な手順を順番に見ていきます。
Entra参加とドメイン参加の違いを理解する
設定に入る前に、なぜ「Entra IDアカウントではピアSMBにそのままSSOできないのか」を簡単に整理しておきます。これを把握しておくと、なぜローカルアカウント方式に切り替える必要があるのかが腹落ちします。
| 項目 | ドメイン参加（AD DS） | Entra参加（Microsoft Entra ID） |
|---|---|---|
| ID基盤 | オンプレAD（ドメインコントローラー） | クラウドのEntra ID |
| SMB認証のメイン方式 | Kerberos / NTLM（ドメインアカウント） | 基本はローカルアカウントやサーバー側のAD/Entra連携アカウント |
| PC同士のピア共有 | ドメインアカウントでSSOしやすい | EntraアカウントSSOは原則対象外。 ローカルアカウントでの認証が現実解 |
| ファイルサーバー | AD参加のWindows ServerでSSOが容易 | Azure FilesなどEntra対応サービスでSSO可能 （ただしPC間ピア共有とは別物） |
要するに、「PC間共有＝ピアSMB」にEntra IDのSSOをそのまま期待するのは設計としてミスマッチということです。そのため、共有側PCのローカルアカウントを中心に据えた設計が必要になります。
最短で復旧するためのチェックリスト
ネットワーク到達性とネットワークプロファイルを正す
まずは土台となる「物理〜L3レベルの到達性」を確認します。ここが怪しいままだと、どれだけSMBやアカウントを調整しても接続できません。
- ネットワークプロファイルを「プライベート」に変更（共有側・接続側の両方） Windows 11の既定では、新しいネットワークは「パブリック」になることが多く、これだとネットワーク探索やファイル共有が制限されます。 変更手順（Windows 11）：
- 「設定」 → 「ネットワークとインターネット」
- 利用中の接続（Wi-Fi または イーサネット）をクリック
- 「ネットワーク プロファイルの種類」を 「プライベート」 に変更
- 検証用にpingを解放（任意だがおすすめ） 疎通確認のため、ICMPエコーを一時的に許可します。
- 「Windows Defender ファイアウォールの詳細設定」
- 「受信の規則」から「ファイルとプリンターの共有（エコー要求 – ICMPv4）」を有効化
- プロファイルは少なくとも プライベート を有効にする
- ポート445の到達性を確認（Test-NetConnection） 接続側PCからPowerShellで次を実行します。
Test-NetConnection <共有PCのIP> -Port 445結果の見方： 結果 意味 次に見るポイント Ping 成功 / Port 445 = True L3〜L4までは到達。SMBレベル・認証の問題 ファイアウォールのSMB-In、共有設定、認証情報 Ping 失敗 / Port 445 = False ネットワークかFirewallでブロック VLAN/ルータ/ゲートウェイ、クライアント・サーバー両方のFirewall
ネットワーク探索とファイアウォールの設定を見直す
到達性が確認できたら、SMB共有と探索に必要な機能を有効化します。
- ネットワーク探索とファイル共有を有効化 「設定」 → 「ネットワークとインターネット」 → 「共有の詳細設定」で、プライベートネットワークに対して次をONにします。
- ネットワーク探索を有効にする
- ファイルとプリンターの共有を有効にする
- Firewallの受信規則を有効化（共有側PC） 特に共有側PCで、以下の規則が有効になっているか確認します。
- 「File and Printer Sharing (SMB-In)」
- 「Network Discovery」関連一式（SSDP / UPnP / FDResPub など）
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Private Set-NetFirewallRule -DisplayGroup "Network Discovery" -Enabled True -Profile Private - 探索系サービスを起動（共有側PC） サービスが停止していると、名前解決やエクスプローラーの「ネットワーク」に表示されません。
- Function Discovery Resource Publication（自動・遅延開始）
- SSDP Discovery
- UPnP Device Host
認証方式をローカルアカウントベースに切り替える
ここがEntra参加環境での最大のポイントです。Entraアカウント（ユーザー@tenant.onmicrosoft.com 等）でそのまま共有にアクセスさせようとするのはNGと考えてください。
- 共有側PCに共有専用のローカルユーザーを作成 例として、スキャンデータ保存用のユーザーを作成します。
- ユーザー名：
scanuser - パスワード：複雑なものを設定（定期ローテーション方針も決めておく）
- ユーザー名：
- 共有フォルダーの共有許可とNTFS権限を設定
- 共有タブの「アクセス許可」：
scanuserまたは必要最小限のグループを追加し、必要なアクセス権（読み取り/変更など）を付与 - セキュリティタブ（NTFS権限）：同じく
scanuserを追加し、実際の運用に必要な最小権限を付与
- 共有タブの「アクセス許可」：
- クライアントから接続するときの資格情報の書き方 接続パスは次のどちらかです。
\\<共有PC名>\共有名\\<共有PCのIPアドレス>\共有名
<共有PC名>\<ローカルユーザー名>例：- ユーザー名：
PC01\scanuser - パスワード：ローカルユーザー
scanuserのパスワード
- 「コントロール パネル」 → 「資格情報マネージャー」 → 「Windows資格情報」
- 「Windows資格情報の追加」から、共有パス・ユーザー名・パスワードを登録
よくある間違いは、ユーザー名に ユーザー名@tenant.onmicrosoft.com や ユーザー名@自社ドメイン をそのまま入力してしまうケースです。Entra参加PC同士のピアSMBでは、これは基本的に通りません。
SMBプロトコルと複合機の対応状況を確認する
PC同士は接続できても、「複合機だけSMBスキャンがどうしても通らない」ケースは非常に多いです。この場合、SMBプロトコルのバージョンと署名の要件を疑います。
- SMBv1は無効のままにし、SMBv2/v3が有効なことを確認 Windows 11ではSMBv1は脆弱性の観点から無効が推奨です。共有側PCで次を実行して設定を確認します。
Get-SmbServerConfiguration出力の中のEnableSMB1ProtocolがFalseであることを確認し、EnableSMB2ProtocolがTrueになっているかチェックします。 - 複合機のSMB対応バージョンと署名サポートを確認 古い複合機の中には、
- SMBv1しかサポートしていない
- SMB署名に非対応
- 複合機のファームウェアを最新に更新（SMBv2/v3・署名対応版にする）
- ベンダーのマニュアルで「SMB署名」や「SMBv2/v3」対応状況を確認
- どうしても非対応の場合は、SMBをあきらめてFTP/SMTP送信や専用クライアントへ移行を検討
名前解決とIPアドレスの固定化
「IPではつながるのに、コンピューター名ではつながらない」という場合は、名前解決の不安定さが疑われます。
- まずはIPアドレスで接続し、SMB自体が動くかを確認
- DHCPサーバーで共有側PCのIPアドレスを予約して固定
- どうしても名前解決が安定しない環境では、クライアント側の
hostsファイルに最終手段として登録
長期的には、小規模環境であっても簡易DNSサーバーを導入し、PC名とIPを一元管理するとトラブルが減ります。
現場ですぐ使える切り分けフロー
実際の現場で「とりあえずどこから見ればいい？」というときに使える、簡易チートシートです。
Test-NetConnection <IP> -Port 445を実行- NGなら：ネットワークまたはファイアウォールの問題
- OKなら：SMB/認証周りの問題
- 共有側PCのネットワークプロファイルが「プライベート」か確認
- Network Discovery & File and Printer Sharing がON になっているか確認
- Firewallの「File and Printer Sharing (SMB-In)」が有効か確認
- 共有側PCにローカルユーザー作成 → 共有許可/NTFS権限付与
- クライアントから
\\<IP>\共有へPC名\ユーザー形式で接続 - 複合機の場合は、SMBv2/署名対応とファームウェア更新状況を確認
コマンドと目的をまとめると、次のようになります。
| コマンド | 目的 | 想定される結果 |
|---|---|---|
Test-NetConnection <IP> -Port 445 | TCP 445ポートの到達性確認 | TrueならSMBレベルの問題、Falseならネットワーク/Firewall |
ping <IP> | 基本的なL3疎通確認 | 応答なしならFirewallまたはネットワーク構成を確認 |
Get-SmbServerConfiguration | SMBバージョン・署名設定の確認 | SMBv1無効・SMBv2有効であることを確認 |
よくある落とし穴とその対策
Entra参加後のファイル共有トラブルで、本当によく見かけるパターンを整理します。
- ネットワークプロファイルが「パブリック」のまま これだけでネットワーク探索やファイル共有ががっつり制限されます。ドメイン環境時は自動で「ドメイン」プロファイルだったため、移行時に見落とされがちです。
- 「ファイルとプリンターの共有（SMB-In）」が無効のまま ウイルス対策製品やセキュリティテンプレートの適用で、意図せず無効になっていることがあります。グループポリシー（ローカルポリシー含む）で上書きされていないかも確認しましょう。
- 資格情報をEntra ID形式で入力している 例：
[email protected]のような形式で入力しても、ピアSMBでは認証できません。必ずPC名\ユーザー名形式でローカルアカウントを指定します。 - 古い複合機がSMBv1前提・署名非対応 Windows側のセキュリティ標準が上がるにつれ、古い複合機との相性問題は増えています。短期的な暫定対応ではなく、機器更新やFTP送信への切り替えなど、中長期的な対策も検討しましょう。
- セグメントをまたいで445/TCPが閉じている 「同じ社内ネットワークのはず」でも、実際にはVLANやセグメントが分かれており、L3機器やUTMで445がブロックされていることがあります。ネットワーク構成図とACLを確認しましょう。
運用上のベストプラクティスと再発防止策
単発で復旧しても、設計が変わっていなければまた同じトラブルが起きます。Entra参加環境でローカル共有を継続利用する場合、次のような運用ルールを決めておくと安定します。
共有用ローカルアカウントの標準化
- 共有用アカウントの命名規則（例：
sh_user01、scan_<部署名>など）を決める - 権限を最小限に絞る（読み取り専用、変更可能など役割を明確化）
- パスワードの管理・ローテーションルールを文書化する
資格情報マネージャーの一括配布
クライアント台数が多い場合、手作業で資格情報を登録するのは非現実的です。スクリプトやIntune、各種管理ツールを使い、資格情報マネージャーへの登録を自動化すると、ユーザーの問い合わせも減ります。
共有は専用サーバーやクラウドへ集約する
PC間共有は便利な反面、
- PCの電源が落ちると共有も止まる
- バックアップや履歴管理が難しい
- 誰がどこに何を共有しているのか把握しづらい
といった問題があります。可能であれば、次のような選択肢も検討してください。
- 小規模でも良いので、ファイルサーバーやNASを用意して共有を集約
- Microsoft 365 環境なら、SharePoint Online や OneDrive for Business を活用
- Azure Files など、Entra ID連携が可能なストレージサービスの活用
特に「Entra IDでSSOしたい」「社外からも安全にアクセスしたい」といった要件がある場合、PC間共有ではなくサーバー側の設計を見直す方が長期的には安全で運用コストも下がります。
複合機は計画的に更新し、SMBv2対応機種に統一
SMBv1依存の古い複合機を残したままにすると、いつまでもセキュリティと相性の悪い設定を続けることになりがちです。
- 機種ごとのSMB対応状況とファームウェアの更新可否を棚卸し
- SMBv2/v3対応・署名対応機種へ順次リプレース
- どうしても古い機種を残す場合は、SMB以外（FTPやメール送信）に役割を切り替える
ケース別：複合機のSMBスキャンが失敗するときのチェックポイント
Entra参加というより「Windows 10/11のセキュリティ強化」と「複合機の古さ」がぶつかっているケースも多いです。複合機からのスキャンが失敗するときは、以下を順に確認しましょう。
- 複合機から指定しているIPアドレス／ホスト名が正しいか
- 共有フォルダーのパスが正しいか（例：
\\PC01\scan） - 資格情報として指定しているユーザー名が
PC名\ローカルユーザー形式か - 複合機の時刻がずれていないか（認証失敗の原因になる場合あり）
- 複合機のファームウェアを最新に更新しているか
- ベンダーの設定例（機種別マニュアル）を参考に、Windows 10/11向けの設定になっているか
- それでもダメな場合は、SMBからFTP/メール送信へ方式変更できるか検討
特に、ユーザー名とパスワードは「複合機の設定画面に入るアカウント」と混同されやすいので、共有側PCに作ったローカルユーザーの資格情報であることを現場の運用マニュアルにも明記しておくとトラブルが減ります。
まとめ：Entra参加後もローカル共有を使い続けるために
Microsoft Entra参加（旧Azure AD参加）のPC同士でローカル共有フォルダーに接続できない場合、焦って「Entra IDのせい」と考えてしまいがちですが、実際には次のポイントを押さえることで多くのケースが解決します。
- ネットワークプロファイルを「プライベート」にし、Network Discovery と File and Printer Sharing を有効化する
- Firewallで「File and Printer Sharing (SMB-In)」や関連ルールを許可する
- 共有側PCにローカルアカウントを作成し、
PC名\ユーザー名形式で認証する - SMBv2/v3を前提とし、SMBv1依存の機器は更新または他方式へ移行する
- IPと名前解決を整理し、必要ならDHCP予約やhosts登録で安定させる
短期的には上記の手順で「最短復旧」を目指しつつ、中長期的にはファイルサーバーやクラウドストレージへの集約、複合機の更新などを進めていくことで、Entra参加時代にふさわしいシンプルで安全なファイル共有基盤へ移行していくことができます。
まずは今回紹介したチェックリストに沿って、プライベート化・探索/SMB受信許可・ローカル認証の3点から順番に確認していきましょう。
コメント