Microsoft 365 を中心にクラウド完結で運用していると、ファイルだけは大容量やローカルアプリの都合でオンプレに置きたくなることがあります。ここでは「Windows Server を Microsoft Entra ID に参加させ、Entra のユーザー／グループで共有フォルダー権限を管理したい」という相談に、設計の現実解を整理します。
結論：オンプレミスの Windows Server は Microsoft Entra ID に直接「参加」できない
まず押さえるべき結論は明快です。Windows 10/11 で一般的な「Microsoft Entra 参加（旧 Azure AD 参加）」のように、オンプレミスの Windows Server を Entra ID に直接参加させて、Entra のユーザー／グループをそのままローカルの共有フォルダー（SMB）のアクセス制御に使う、という運用は（少なくとも 2024年2月時点の整理では）基本的にサポートされていません。
そのため、やりたいことをそのまま実現しようとすると、どこかで設計を切り替える必要があります。ポイントは次の3つです。
- Windows Server の共有フォルダー権限（NTFS ACL / 共有権限）は、基本的に AD DS（オンプレ Active Directory ドメイン） を前提にした世界観で動いている
- 「ハイブリッド参加」や「同期」を使っても、AD DS をゼロにするという目的は達成しにくい
- AD DS を置かないなら、共有フォルダーそのものを別のファイルサービスに置き換える（Azure 側のファイル基盤や Entra 連携ストレージ等）発想が近道になりやすい
なぜできないのか：Entra ID と AD DS は“似て非なる”別物
「ID が Entra に集約できているのだから、サーバーも Entra に参加させればよいのでは？」と考えがちですが、Entra ID と AD DS は目的も得意領域も違います。特に SMB（ファイル共有）の認証と権限管理は、長年 AD DS の Kerberos/NTLM を前提に進化してきました。
| 観点 | Microsoft Entra ID（クラウドID） | AD DS（Active Directory ドメイン） |
|---|---|---|
| 主な役割 | SaaS へのサインイン、条件付きアクセス、MFA、ID ガバナンス | オンプレ Windows のドメイン参加、Kerberos、GPO、ファイル共有/プリンタ等の基盤 |
| 代表的な認証 | OpenID Connect / OAuth 2.0 / SAML | Kerberos / NTLM |
| 端末の参加形態 | Windows 10/11 の Entra 参加、MDM（Intune）中心 | Windows Server/PC のドメイン参加、GPO 中心 |
| SMB 共有フォルダーの権限 | そのままでは扱えない（SID ベース権限と直結しない） | 得意分野（ユーザー/グループの SID で ACL を構成） |
ざっくり言うと、Entra ID は「クラウドアプリに安全にサインインする」ための仕組み、AD DS は「Windows のネットワーク機能（特に SMB）を成立させる」ための仕組みです。ファイルサーバーを置くという要件が入った瞬間に、AD DS の世界観が強く求められます。
共有フォルダー（SMB）のアクセス制御が AD DS 寄りになりやすい理由
Windows Server の共有フォルダーは、多くの現場で次のような構造で権限を決めています。
- 共有権限：共有そのものに対する入口（例：Everyone フルコントロールにして NTFS で絞る運用も多い）
- NTFS 権限（ACL）：フォルダー/ファイル単位の細かな権限（読み取り/変更/フルなど）
- 上記の主体は、基本的に ユーザー/グループの SID（セキュリティ識別子）で評価される
この「SID で評価される」という点が重要です。Entra のユーザー/グループはクラウドの識別子を持ちますが、オンプレの Windows Server が SMB 権限評価に使う SID と直接一致しません。結果として、“Entra のグループだけで共有フォルダー権限を完結させる”のが難しくなります。
AD DS を置かずに Windows Server をファイルサーバーにした場合に起きること
AD DS を使わずにファイルサーバーを運用する方法が全くないわけではありません。例えば「ローカルユーザー/ローカルグループ」で権限を付けることはできます。ただし、次のような運用課題がほぼ確実に出ます。
- ユーザー作成・退職対応・パスワード管理が サーバーごと になり、属人化しやすい
- クライアントが変わるたびに資格情報を入れ直すなど、ユーザー体験が悪い
- 監査・ログ分析・アクセスレビューを “クラウドのやり方” で統一しにくい
- 台数が増えるほど、同じ設定を揃えるコストが跳ね上がる
「AD DS を置きたくない」理由が運用負荷だとすると、ローカルユーザー方式は逆に負荷が増えるケースが多いです。
“ハイブリッド参加”はできても、AD DS をなくす方向には直結しない
相談でよく出る言葉が「ハイブリッド参加（Hybrid join / Hybrid Azure AD Join）」です。これは大雑把に言うと、AD DS にドメイン参加している端末（主に Windows 10/11）を、Entra 側にも登録する考え方です。
ハイブリッド参加は、条件付きアクセスや Intune と組み合わせた端末制御に効きます。しかし、共有フォルダーの権限評価そのものは AD DS の SID と Kerberos に依存し続けるため、「AD DS なしでファイル共有を運用したい」という目的は残る、というのが実務上の結論になりがちです。
| やりたいこと | ハイブリッド参加で解決しやすい | ハイブリッド参加だけでは解決しにくい |
|---|---|---|
| 端末の状態に応じてアクセス制御したい | ○（条件付きアクセス/準拠デバイスなど） | — |
| SMB 共有への SSO を成立させたい | △（構成次第。結局 AD DS が前提） | — |
| 共有フォルダー権限を Entra グループだけで管理したい | — | ×（AD DS 側のグループ/SID が必要になりやすい） |
| オンプレ AD（AD DS）をなくしたい | — | ×（AD DS が存在しないと成立しない機能が多い） |
「Entra のユーザー／グループで管理したい」を現実的に満たす考え方
ここで多くの組織が行き着くのが、「共有フォルダーの ACL は AD DS を使うが、グループ運用の中心を Entra に寄せる」という折衷案です。ポイントは、SMB の権限評価は AD DS の SID で行われるため、最終的にファイルサーバーが参照できる“ドメイン グループ”が必要になることです。
よくある運用パターン
| パターン | グループを作る場所 | メンバー管理の中心 | 向いている組織 | 注意点 |
|---|---|---|---|---|
| クラシック（堅実） | AD DS | AD DS | ファイル共有が中核。運用を単純にしたい | クラウド完結感は薄れるが、最もトラブルが少ない |
| 同期して再利用 | AD DS | Entra/AD DS 併用 | M365 側でも同じグループを使いたい | 同期の対象/命名/変更手順を決めないと混乱する |
| クラウド中心（できる範囲で） | Entra | Entra | クラウド運用を崩したくない | オンプレ側へ“書き戻し”が必要な場合があり、ライセンス/方式/制約の確認が必須 |
特に「クラウド中心（Entra でグループを作りたい）」を選ぶ場合は、そのグループがオンプレ側にどう届くのか（書き戻しが可能か、別途同名グループを作る必要があるか）を最初に確認してください。ここを曖昧にすると「管理画面上はメンバーなのにアクセスできない」「抜いたはずの人がアクセスできる」といった事故につながります。
選択肢を整理する：目的別の“現実解”マップ
理想（AD DS を置かず、Entra のユーザー/グループだけで共有フォルダーを運用したい）をそのまま追うと詰まりやすいので、目的を分解して、実現しやすい組み合わせに落とします。
| 選択肢 | 向いている状況 | メリット | 注意点 |
|---|---|---|---|
| 最小構成の AD DS + ファイルサーバー | オンプレに SMB が必要、権限管理を王道でやりたい | 実装が素直、権限設計の自由度が高い、トラブルシュートしやすい | AD DS の維持が必要（冗長化/バックアップ/運用ルール） |
| オンプレに DC を置かず、マネージド ドメインを使う | 拠点に DC を持ちたくないが、ドメイン参加と SMB は必要 | ドメイン運用の一部をサービス側に任せられる | ネットワーク要件が強い。できること/できないこと（管理権限や拡張性）を把握する必要 |
| ファイル基盤を Azure に移す（Azure 側のファイルサービス） | “オンプレに置く”理由が薄い、回線/遅延が許容できる | オンプレ依存を減らせる、バックアップ/可用性を設計しやすい | 回線品質が重要、アプリ互換や性能評価が必要 |
| クラウドファイル + ローカルキャッシュ（同期） | 大容量だが“よく使うデータは一部”、拠点に高速アクセスが欲しい | クラウドを正として、拠点にキャッシュを置ける | 排他制御/ロックの考え方、運用監視が必要 |
| Entra 連携できる NAS/ストレージを採用 | Windows Server を置く理由が薄い、ストレージ機器で完結したい | サーバー運用を減らせる可能性 | “Entra 連携”の範囲が製品で大きく違う（SMB ACL まで届くか要確認） |
おすすめの落としどころ：AD DS は“最小限”にして、権限管理を破綻させない
共有フォルダー（SMB）を「ユーザー/グループで素直に」管理したいなら、結局 AD DS に寄せるのが一番トラブルが少ないです。とはいえ、クラウド完結から後戻りする必要はありません。AD DS を“必要最小限の基盤”として割り切ると、現実的なバランスが取れます。
最小構成の例
- ドメインコントローラーは 2台（冗長化）。可能なら Server Core で攻撃面を縮小
- ファイルサーバーは別サーバーとして用意（役割分離）
- ユーザー/グループは AD DS にも存在させ、Microsoft 365 側と整合させる（同期設計）
- グループ設計は「共有単位」で作り、直接ユーザーを ACL に入れない（運用が回る）
導入の流れ（既存クラウド環境から追加する場合の考え方）
クラウド完結で既に運用している場合、いきなり本番データを移すと混乱します。次の流れで“小さく始めて安全に広げる”のが現場では強いです。
- 共有フォルダーに置く対象データと、アクセスが必要なユーザー/部署を棚卸しする
- AD DS のドメイン設計（名前、DNS、冗長化、バックアップ）を決め、最小構成で構築する
- Entra と AD DS の整合を取る方針（同期・アカウント合わせ・グループ運用）を決める
- テスト用の共有フォルダーを作り、端末（Entra 参加/ドメイン参加の両方）からのアクセス体験を確認する
- 運用ルール（申請・棚卸し・監査・退職時の無効化）を決めてから本番移行する
権限グループの作り方（実務で揉めにくい命名例）
現場でよく詰まるのが「誰に何を付けたか分からない ACL」です。おすすめは、共有フォルダー単位で 読み取り用 / 変更用のグループを用意して、ユーザーは必ずグループに所属させる形です。
| 対象 | グループ例 | 付与する権限 | メモ |
|---|---|---|---|
| 部署共有（例：経理） | FS_Keiri_RW | 変更 | 担当者のみ |
| 部署共有（例：経理） | FS_Keiri_RO | 読み取り | 参照のみのメンバー |
| プロジェクト共有（例：PJ-A） | FS_PJA_RW | 変更 | 外部協力会社を含める場合は運用ルール必須 |
| プロジェクト共有（例：PJ-A） | FS_PJA_RO | 読み取り | 監査ログと棚卸し（アクセスレビュー）をセットで |
そして共有権限は、運用を単純化するために「認証済みユーザー（または対象グループ）にフル、細かい制御は NTFS」で統一すると、後で説明がしやすくなります（もちろん組織ポリシーに合わせて調整してください）。
Entra 参加端末からオンプレ共有にアクセスする時の“体験”に注意
クラウド完結環境では、端末は Entra 参加で運用しているケースが多いです。このとき、ファイルサーバー側を AD DS ドメインにすると、ユーザーのアクセス体験が次の2パターンに分かれます。
| 端末の状態 | オンプレファイル共有へのアクセス | ユーザー体験 | 運用面のポイント |
|---|---|---|---|
| 端末がドメイン参加（またはハイブリッド参加） | Kerberos で SSO しやすい | ○（通常は資格情報の入力不要） | GPO/MDM の棲み分けが必要 |
| 端末が Entra 参加のみ（ドメイン非参加） | AD DS 資格情報を明示してアクセスすることが多い | △（認証の促しが出やすい） | 資格情報の扱い、ドライブマップ手順、サポート負荷を見積もる |
「端末は Entra 参加のままにしたい」場合、共有フォルダーにアクセスできること自体は可能でも、認証の促しが頻発したり、部署異動時に「古い資格情報が残ってアクセスできない」といった問い合わせが増えやすいです。導入前に、代表ユーザーで実機テストし、運用サポートの想定問答を作っておくと事故が減ります。
AD DS を立てたくない場合の代替案：ファイル基盤を Azure 側に寄せる
「どうしてもオンプレ AD（AD DS）を置きたくない」という軸を貫くなら、オンプレの Windows Server で“従来型の SMB 共有”を作る発想から離れるのが近道です。具体的には、ファイル基盤を Azure 側に寄せて、Entra を軸にした運用へ寄せていきます。
パターン：Azure のファイルサービスを正とし、拠点はキャッシュ/同期で補う
- クラウド側にファイル共有（Azure 側のファイルサービス等）を置き、拠点には必要に応じてキャッシュや同期を配置する
- アクセス制御は、可能な範囲で Entra のユーザー/グループ運用に寄せる（ただし方式や制約はサービス仕様に依存）
- 回線障害時の業務継続（BCP）要件がある場合は、オフライン時の動きまで含めて設計する
この構成の良いところは、「オンプレにドメイン基盤を置く」運用を避けつつ、拠点側に高速アクセスの居場所を作れる点です。一方で、クラウド回線品質、ロック/同時編集、バックアップ設計、コスト最適化など、検討項目は増えます。
ワークロードを Azure VM に載せる案：オンプレに置く理由を“場所”から切り離す
「どうしても Windows Server（アプリやバッチ）が必要」「ただし設備は増やしたくない」という場合は、オンプレではなく Azure 上の仮想マシンとして Windows Server を用意し、拠点からは VPN/専用線でアクセスする構成も候補になります。
- メリット：ハードウェア保守・設備更改の手間が減る。可用性やバックアップを設計しやすい
- 注意点：ファイル共有用途は回線品質の影響が大きい。オンプレの“LAN速度”を期待するとギャップが出やすい
- 割り切り：サーバーが Azure にあっても、SMB の権限設計は結局どの認証基盤を使うかで決まる
「Azure に載せれば Entra だけで全部いける」と短絡せず、認証・権限・回線をセットで評価するのが失敗しないコツです。
オンプレに DC を置かない折衷案：Microsoft Entra Domain Services（マネージド ドメイン）
「オンプレに AD DS を置きたくないが、ドメイン参加と SMB は必要」という場合、Azure 側のマネージド ドメイン（旧 Azure AD Domain Services、現 Microsoft Entra Domain Services）を使う発想もあります。これは “AD DS 相当の機能をサービスとして提供” するもので、DC を自前で運用する負荷を下げられる可能性があります。
- メリット：DC のパッチ/冗長化などの運用負荷を抑えやすい
- 注意点：ネットワーク接続（VPN/専用線）の品質が重要。管理できる範囲が通常の AD DS と異なる
- 割り切り：「AD をなくす」のではなく「AD を自前運用しない」方向の解決策
“AD DS をゼロにしたい”という理想からは外れますが、オンプレ運用を極力増やしたくない組織では現実的な選択肢になり得ます。
SharePoint/OneDrive を継続する場合に見直したいポイント
既に SharePoint/OneDrive を中心に回っているなら、「オンプレにファイルサーバーを増やす」前に、現行のクラウド運用を少し見直すだけで解決できることもあります。
- 大容量ファイルの扱いがネックなら、同期方式（選択的同期、オンデマンド）とライブラリ設計（分割/権限境界）を見直す
- ローカルアプリ都合で共有が必要なら、アプリが求める条件（ファイルロック、パス長、同時編集）を整理し、代替手段がないか検討する
- 社内ネットワーク前提の運用が残っているなら、まずは VPN・回線・端末性能のボトルネックを切り分ける
「何を理由にオンプレが必要なのか」を言語化できると、Azure 側へ寄せるのか、最小 AD DS にするのか、NAS にするのかの判断が一気にしやすくなります。
NAS／ストレージで“Entra 連携”を検討する際のチェックポイント
「Windows Server を置かずに済むなら、NAS でよいのでは？」という判断もよくあります。ただし、製品カタログの「Azure AD / Entra 対応」は範囲が広く、何ができるのかを具体的に確認しないと失敗します。
| 確認ポイント | 質問例 | 落とし穴になりやすい点 |
|---|---|---|
| 認証方式 | Entra での SSO ができるのは管理画面だけ？ SMB アクセスも？ | 管理画面の SSO だけで、SMB のユーザー/グループは別管理というケース |
| グループ連携 | Entra のグループをそのまま ACL に使える？ 同期周期は？ | グループは参照できても、ACL 反映は手作業・別機構というケース |
| 監査ログ | 誰がどのファイルにアクセスしたか追える？ 取り出しやすい？ | ログはあるが粒度が粗い/保持が短い/SIEM 連携が弱い |
| ランサムウェア対策 | スナップショット、WORM、オフラインコピーの運用は？ | 機能があっても運用が回らないと復旧できない |
| アプリ互換 | 既存のローカルアプリが SMB に強依存していないか？ | ファイルロックやパスの扱いで想定外の不具合が出る |
「Entra でグループ管理したい」という目的は、NAS で達成できる場合もありますが、達成できる範囲が製品ごとに違います。PoC（検証）では、実際の Windows クライアントからの SMB アクセスと、権限の反映・撤回・監査までを一通り試すのが安全です。
「サーバーも Entra で管理したい」の別解：参加ではなく“管理プレーン”をクラウドに寄せる
「参加できないのは分かったが、せめて運用管理はクラウドに寄せたい」というニーズもあります。この場合、焦点を「ドメイン参加」から「運用の見える化・一元管理」に移すと前に進みます。
- 更新プログラムや構成管理を標準化し、サーバーの状態を把握できるようにする
- EDR/ウイルス対策、脆弱性評価、ログ収集を統一して、インシデント対応の速度を上げる
- リモート管理の入口を整理し、誰が何をしたか追えるようにする
これらは SMB 権限の話とは別軸ですが、「オンプレ Windows Server を置くなら運用の属人化が最大のコストになる」という現場感からすると、早めに手当てしておく価値が高い領域です。
セキュリティ面の注意：クラウドの“条件付きアクセス”は SMB にはそのまま効かない
クラウド中心の運用に慣れていると、つい「MFA や条件付きアクセスで守れるから大丈夫」と考えがちです。しかし、オンプレの共有フォルダー（SMB）アクセスは、基本的に社内ネットワーク/ VPN 内の Kerberos/NTLM の世界で成立します。つまり、クラウドの制御だけでは守り切れない部分が出ます。
- ネットワーク制御：アクセス元セグメントを限定、VPN は MFA 付き、不要なポートを閉じる
- SMB の堅牢化：SMBv1 無効化、署名/暗号化、管理共有の扱い、ローカル管理者権限の棚卸し
- 監査：重要共有は監査ポリシーとログ転送（保管）をセットで
- バックアップ/復旧訓練：スナップショットだけに頼らず、世代管理と復旧手順の演習まで行う
ファイルサーバーはランサムウェアの主要ターゲットです。設計段階で「権限管理」だけでなく「感染時に何時間で復旧できるか」まで決めておくと、経営層への説明もしやすくなります。
PoC（検証）で確認すると失敗しにくいポイント
どの案を選ぶにせよ、検証で「動いた/動かない」だけを見ると本番で揉めます。次の観点をセットで確認すると、運用の地雷を踏みにくくなります。
- 端末が Entra 参加のみの場合でも、現場の業務フローで迷わずアクセスできるか（資格情報の扱い含む）
- 権限付与・権限撤回が、どの画面/どの申請で回るか（担当者が替わっても回るか）
- 監査ログで「誰が」「いつ」「どのフォルダーに」アクセスしたか追えるか
- バックアップからの復旧で、共有/ACL まで含めて戻せるか（復旧時間も計測）
- 回線遅延や一時断が起きたとき、アプリやユーザー操作にどんな影響が出るか
よくある質問
Windows Server は将来的に Entra 参加できるようになりますか？
ロードマップは変わり得るため断言はできませんが、少なくとも従来の「ドメイン参加の置き換え」として、オンプレの Windows Server を Entra 参加させる前提で設計してしまうのはリスクが高いです。実現したい要件（共有フォルダー、アプリ、認証方式）を先に固め、今の仕組みで成立する構成に落とし込むほうが安全です。
Entra の動的グループを共有フォルダーの ACL に使えますか？
SMB の ACL は基本的に AD DS の SID を前提に評価されるため、Entra の動的グループをそのまま ACL に指定する、という形は取りづらいのが一般的です。共有権限をグループで管理したい場合は、最終的にファイルサーバーが参照できる形（ドメイン グループ）へ落とす設計が必要になります。
共有フォルダーに対して MFA を必須にできますか？
クラウドアプリのように「ファイルにアクセスするたびに MFA」を強制するのは難しいケースが多いです。代わりに、VPN を MFA 付きにする、アクセス元ネットワークを制限する、端末のセキュリティ基準を満たした場合のみ接続させる、といった入口の制御でリスクを下げます。
小規模なので DC を1台で済ませたいのですが？
技術的に1台で動く場面はありますが、停止した瞬間に認証や名前解決に影響が出やすく、結果として業務停止リスクが高くなります。ファイルサーバーを業務の中核に置くなら、最小でも冗長化（2台）を前提に考えるほうが、長期的にはコストとトラブルが減ることが多いです。
判断のチェックリスト：どの案に寄せるべきか
最後に、要件を聞き取るときに使えるチェックリストを置いておきます。○が多い列が、だいたい向いている方向です。
| チェック項目 | オンプレ SMB + AD DS | Azure 側のファイル基盤 | NAS/ストレージ |
|---|---|---|---|
| ローカルアプリが UNC パスやファイルロックに強依存している | ○ | △（要検証） | △（要検証） |
| 回線遅延に弱く、拠点での高速アクセスが必須 | ○ | △（キャッシュ/同期で補う） | ○ |
| オンプレのサーバー運用を増やしたくない | △ | ○ | ○（ただし機器運用は残る） |
| ユーザー/グループの権限設計を柔軟にやりたい | ○ | △（サービス仕様に依存） | △（製品仕様に依存） |
| “AD DS を置かない”ことが絶対条件 | × | ○（構成次第） | ○（構成次第） |
まとめ：目的を「Entra だけで」に固定せず、運用・体験・コストで最適化する
オンプレミスの Windows Server を Microsoft Entra ID に直接参加させ、Entra のユーザー/グループで共有フォルダー（SMB）の権限を完結させる、という構想は、現状の Windows Server/SMB の前提と噛み合いにくいのが実情です。
だからこそ、次のどれを優先するかで設計を決めるのが現場では強いです。
- 共有フォルダーを王道運用したい → AD DS を最小構成で用意して破綻を防ぐ
- オンプレに AD を置きたくない → マネージド ドメインやクラウド側のファイル基盤へ寄せる
- どちらも譲れない → まず PoC を回し、アクセス体験と運用負荷を数値で比較して決める
“正解は一つ”ではありませんが、SMB 共有を置く以上、AD DS の概念を無視して進めると後で必ずしわ寄せが来ます。要件を分解し、できるだけシンプルな形で落とし込むことが、長期的に一番コストを下げる近道です。
コメント