Windows Server 2016のファイルサーバーで、新しく作成したドメイン管理者アカウントで共有フォルダーを開くと「権限がありません（続行しますか）」が出るのに、続行すると開ける――この挙動は“権限の持ち方”が原因で起きます。
原因の切り分けから、安全に直す手順、二度と同じ画面を出さない権限設計までをまとめます。
まず結論：なぜ「権限がない」画面が出るのか
この症状の本質はシンプルで、その新しいドメイン管理者アカウント（または所属グループ）が、対象フォルダーのアクセス権（NTFS権限）を“最初から”持っていないことが主因です。
それなのに［続行］を押すとフォルダーが開けるのは、管理者権限を持っているために、エクスプローラーが「管理者としての救済動作」（権限の付与／所有権取得／ACLの修正など）を実行できてしまい、結果としてアクセスできる状態に変えているケースが多いからです。
言い換えると、毎回表示される警告は「バグ」ではなく、今の権限設計だと“通常の許可では入れない”ことを正直に教えてくれているサインです。
よくある誤解：ドメイン管理者＝どこでも最初から開ける、ではない
ドメイン管理者（Domain Admins）に所属していると「何でもできる」印象が強いのですが、ファイルアクセスの世界では次の2つを分けて考える必要があります。
- 通常のアクセス権：NTFSの許可（読み取り／変更／フルコントロールなど）により、最初から開けるかどうかが決まる
- 管理者の特権：所有権の取得（Take Ownership）やアクセス許可の変更（Change Permissions）など、“入れない状態を変えてしまう”能力がある
今回のように「続行で開ける」場合、前者（通常のアクセス権）が不足している一方で、後者（管理者特権）があるために、エクスプローラーが救済してしまっている可能性が高いです。
症状の意味をもう一段深掘り：［続行］で何が起きている？
Windowsのエクスプローラーには、アクセス拒否時にユーザーを助ける仕組みがあります。ローカルのフォルダーを開く場面では、管理者権限があるユーザーに対して「続行」ボタンを出し、押下後に以下のような処理が走ることがあります。
- 対象フォルダーの所有者をAdministrators（または現在のユーザー）に変更する
- 対象フォルダーのACL（アクセス制御リスト）に、現在のユーザーやAdministratorsを追加し、必要な許可を与える
- 継承設定を変更し、結果として権限構造が“崩れる”
これにより、見た目としては「権限がない→続行→開ける」となります。しかし運用面では、権限が自動的に書き換わるのが最大の問題です。管理者が意図せずアクセス権を付与してしまい、監査や最小権限の観点で望ましくない状態になりやすいからです。
切り分けの最短ルート：まず確認すべき項目
直す前に、どこで詰まっているかを正確に把握しましょう。共有フォルダーは「共有権限」と「NTFS権限」の両方が絡み、最終的なアクセス権は基本的に“両者の積（より厳しい方）”になります。
| チェック項目 | 確認場所 | 見るべきポイント | よくある落とし穴 |
|---|---|---|---|
| 共有権限 | 共有のプロパティ（サーバー側） | ドメイン管理者（または管理グループ）に必要な許可があるか | 共有権限で「読み取り」しかなく、NTFSで変更しても結局できない |
| NTFS権限 | フォルダーのプロパティ → セキュリティ | 対象ユーザー／グループ（Domain Admins等）に許可があるか | 特定ユーザーにだけ許可が付いていて、グループに付いていない |
| 継承 | セキュリティ → 詳細設定 | 継承が無効になっていないか、親からの権限が想定通りか | 途中階層で継承が切れ、管理グループが消えている |
| Deny（拒否） | セキュリティ → 詳細設定 | 意図しない拒否が入っていないか | Denyは強力。許可より優先されて原因が見えにくい |
| 所有者 | セキュリティ → 詳細設定 | 所有者が想定外（退職者、古いSID等）になっていないか | 所有者が不正だと、管理者でも警告が出やすい |
| 有効なアクセス | セキュリティ → 詳細設定 → 有効なアクセス | 新しい管理者IDが実際に持つ権限（読み取り/変更/削除など） | グループ追加後に再ログオンしておらず、トークンが更新されていない |
原因別の“あるある”と対処の方向性
同じ「権限がない」でも原因はいくつかに分かれます。代表例を症状ベースで整理します。
| 見える症状 | 可能性が高い原因 | 確認方法 | 推奨対処 |
|---|---|---|---|
| ［続行］で開ける（ローカルで） | NTFS権限が不足しているが、管理者特権で救済されている | 有効なアクセスで「読み取り」が不足していないか確認 | 管理グループにNTFS権限を明示的に付与し、続行不要にする |
| ［続行］でも開けない／アクセス拒否のまま | 共有権限が足りない、またはDenyが効いている | 共有権限とDenyエントリをチェック | 共有権限を見直し、不要なDenyを整理 |
| 新しい管理者だけダメで、古い管理者は問題ない | 特定ユーザーにのみ許可が付いている（グループで付いていない） | ACLにユーザー名が直書きされていないか確認 | 個人アカウントではなくグループで権限管理に寄せる |
| フォルダー階層によって挙動が違う | 途中で継承が切れている／個別ACLが混在している | 問題の階層で「継承の有効化」を確認 | 親からの継承を基準に再設計し、例外を最小化する |
| 警告が頻発し、権限が勝手に増えていく | ［続行］により管理者が都度ACLを変更してしまっている | 直近でACLが変わっていないか（監査ログやタイムスタンプ） | “続行を押さなくても開ける”正しい権限を付与し、運用ルール化 |
安全で確実な直し方：Everyoneではなく「適切なグループ」に最小権限を付与する
「Everyoneに許可は出したくない」という方針は、セキュリティ上とても妥当です。代わりに、運用単位のグループ（管理用・部門用など）に対して、必要最小限の権限を与えるのが正攻法です。
おすすめの考え方（運用が破綻しにくい）
- 個人アカウントに直接付けない（異動・退職・改名で破綻する）
- 「使う人のグループ」と「管理する人のグループ」を分ける
- 共有権限はシンプルに、実際の制御はNTFSに寄せる（例外を減らす）
権限モデルの例（共有権限とNTFS権限の役割分担）
代表的なモデルを2つ示します。組織のポリシーに合わせて選んでください。
| モデル | 共有権限（Share Permission） | NTFS権限（フォルダーのセキュリティ） | 向いているケース |
|---|---|---|---|
| NTFSで厳密管理（推奨） | 管理グループ：フル 利用者グループ：変更または読み取り（必要に応じて） | 部門フォルダー単位で最小権限（読み取り／変更） 管理グループ：フル（継承） | 運用が長期に渡る共有、権限例外が多い共有 |
| 共有権限も併用 | 共有単位で利用者を絞る（例：部門ごとに別Share） | NTFSは比較的ゆるめ（ただし重要データは例外設定） | Shareが明確に分かれる、小規模・単純な共有 |
今回の症状を止めたいだけなら、少なくとも管理者が使うグループ（例：Domain Admins もしくは管理専用グループ）に、対象フォルダーのNTFS権限を明示的に付与すれば解消しやすいです。
具体的な付与先の例
- 管理者用：Domain Admins、または「FileServer-Admins」のような管理専用グループ
- 利用者用：部門グループ（例：Sales-FS-Users、HR-FS-Users）
- 監査・バックアップ：バックアップ運用専用のサービスアカウント（必要に応じて）
権限の整備手順（GUI）：続行を押さなくても開ける状態を作る
手順はシンプルですが、誤ると広範囲のアクセスが開いてしまうため、実施前にバックアップ（少なくともACLのエクスポート）を推奨します。
- 対象フォルダーを右クリック →［プロパティ］→［セキュリティ］→［詳細設定］を開く
- ［有効なアクセス］で、新しいドメイン管理者IDを選び、現状で「読み取り」すら無いことを確認する
- ［アクセス許可の追加］で、管理用グループ（例：Domain Admins または FileServer-Admins）を追加し、必要な権限（多くはフルコントロール）を付与する
- サブフォルダーまで一貫させたい場合は、適切な継承（このフォルダー、サブフォルダーおよびファイル）になっているか確認する
- 再度［有効なアクセス］で、警告が出ていたユーザーが最初からアクセスできることを確認する
ポイントは「個別ユーザーに付ける」のではなく、グループに付けて運用で回せる形に寄せることです。新しい管理者が増えても、グループに入れるだけで済み、フォルダー側のACLを触らずに済みます。
継承が切れている場合の直し方（“権限がバラバラ”を脱出する）
ファイルサーバーで長年運用している共有では、途中階層で継承が切れていたり、例外ACLが増殖していることが珍しくありません。継承が切れていると、親フォルダーに管理グループの権限を付けても子階層に伝播せず、今回のような症状が発生しやすくなります。
継承の基本ルール
- 親フォルダーの権限が、（設定次第で）子フォルダーへ伝播する
- 途中で「継承を無効」にすると、以降は親の変更が届かなくなる
- 例外を増やすほど、後からの調査・移行・監査が難しくなる
整備の進め方（現場向け）
- 共有の“基準ACL”を決める（管理者フル、利用者は部門別、SYSTEMはフルなど）
- 親フォルダーに基準ACLを設定し、不要な個別ユーザーの直書きを削減する
- 問題の階層で継承が切れているなら、意図した例外なのかを確認する
- 例外でなければ継承を有効化し、権限を親基準へ寄せる
注意：継承を有効化すると、子階層の個別設定が消える（または親に置き換わる）可能性があります。いきなり全階層に適用せず、影響範囲を区切って段階的に進めるのが安全です。
所有者（Owner）を直すべきケースと、直し方の考え方
所有者が不自然な状態だと、管理者でもアクセス時に警告が出やすくなったり、権限の整合性が崩れやすくなります。例えば次のようなケースは要注意です。
- 所有者が退職者アカウントのまま
- SIDだけが表示される（存在しないアカウント）
- 部門フォルダーなのに利用者個人が所有者になっている
一般的なファイルサーバー運用では、所有者をAdministratorsまたはSYSTEM、あるいは明確な管理グループに揃えておくと管理が安定します。必要に応じて「所有者を変更」し、子オブジェクトにも適用する設定を使います。
Deny（拒否）があるときは“まず疑う”
Denyは便利ですが、強力すぎてトラブルの温床にもなります。特に次のような運用だと、意図しない拒否が混ざりやすくなります。
- 「このフォルダーだけアクセスさせない」をDenyで実現している
- 一時的に拒否した設定がそのまま残っている
- 継承＋Denyの組み合わせで、上位で拒否していることに気づかない
| Denyを使うべき場面 | 代替案（推奨） | 理由 |
|---|---|---|
| 例外的に“絶対に禁止”したいアクセスがある | 許可の設計を見直し、そもそも許可を付けない | Denyは調査コストが高く、後任が理解しづらい |
| アプリ都合でどうしても必要 | 対象範囲を最小化し、コメントや運用ドキュメントで理由を残す | 範囲が広いDenyは事故につながる |
コマンドで確認・修正する（icacls / PowerShell）
GUIでも十分ですが、サーバー運用では「現状をテキストで残す」「変更を再現できる」ことが重要です。ここでは、影響が分かりやすい代表コマンドを紹介します。
ACLの現状確認：icacls
対象フォルダーのACLを表示します。
icacls "D:\Shares\Dept"結果に管理用グループ（例：DOMAIN\FileServer-Admins や DOMAIN\Domain Admins）が含まれているか、(OI)(CI) などの継承フラグが適切かを確認します。
権限付与：icacls /grant
管理用グループにフルコントロールを付与する例です（環境に合わせて置き換えてください）。
icacls "D:\Shares\Dept" /grant "DOMAIN\FileServer-Admins:(OI)(CI)F"読み取りだけにする、変更にするなども可能です。権限文字は代表例として F（フル）、M（変更）、RX（読み取りと実行）などがあります。
継承の有効化：icacls /inheritance
継承が無効で、意図せず権限が孤立している場合の例です。
icacls "D:\Shares\Dept" /inheritance:e継承の影響が大きい場合があるため、実行前に対象範囲（どの階層で切れているか）を必ず確認してください。
PowerShellで「有効なアクセス」に近い確認をする
PowerShellではACLを取得して、どの主体にどんな権限が付いているかを確認できます。
$path = "D:\Shares\Dept"
(Get-Acl $path).Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited | Format-Table -AutoSize大量のフォルダーを相手にする場合は、特定グループが存在しないフォルダーを検出するスクリプトを作って棚卸しすると、権限の“穴”を潰しやすくなります。
運用で再発しやすいポイント
グループに追加したのに反映されない
新しい管理者IDをDomain Adminsや管理グループに追加した直後にテストすると、反映されていないように見えることがあります。これは、ログオン時に作られたアクセス・トークンにグループ情報が固定されるためです。いったんサインアウト→サインイン（または再起動／再ログオン）してから再検証しましょう。
共有権限とNTFS権限のどちらかがボトルネックになる
NTFS側を直しても、共有権限が「読み取り」しかなければ書き込みはできません。逆も同様です。最終的なアクセス権は“より厳しい方”になるため、必ず両方をセットで確認します。
［続行］を押すと、権限設計が崩れることがある
一度「続行」で入れてしまうと、そのユーザーがACLに追加され、以後は“その人だけ”は入れる、といった歪な状態になりがちです。最小権限の観点でも、監査の観点でも避けたいので、続行を前提にしない運用に寄せましょう。
管理者アカウントで日常アクセスしない
ドメイン管理者は影響範囲が大きい権限です。ファイルの閲覧・編集のために日常的に使うと、誤操作のリスクが高まります。可能であれば、管理用IDと一般作業用IDを分ける、管理用IDは必要時のみ使う、といった運用にすると安全です。
「管理者でも中身は見ない」方針の場合の落としどころ
組織によっては「ドメイン管理者＝インフラ管理者であり、業務データの閲覧権限は持たせない」という方針もあります。この場合、今回の警告はむしろ正常です。最初からNTFS権限を与えない限り、警告を完全に消すことはできません。
それでも障害対応などで“読む必要がある”場面があるなら、次のような運用を検討します。
- 閲覧が必要な場合は申請・承認フローで一時的にグループへ追加し、期限後に外す
- 監査ログを有効化し、誰がいつ権限を変更したか／アクセスしたかを追えるようにする
- 権限を変えずにバックアップ権限で取得する運用（バックアップ専用アカウント＋ツール）を整備する
重要なのは「続行でこっそり権限が増える」状態を放置しないことです。方針が“見ない”なら見ないで、運用ルールと技術設定を一致させる必要があります。
最終チェックリスト
- 共有権限：管理グループが入っているか（必要な権限か）
- NTFS権限：管理グループが入っているか（継承フラグが適切か）
- 継承：意図せず無効になっていないか
- Deny：不要な拒否が残っていないか
- 所有者：不自然な所有者になっていないか
- グループ反映：追加・変更後に再ログオンしたか
- 運用：［続行］での救済を前提にしていないか（ルール化されているか）
まとめ
Windows Server 2016のファイルサーバーで、新しいドメイン管理者IDが共有フォルダーを開くと「権限がない」画面が出るのに、続行すると開ける――この現象は、“通常のNTFS権限が不足しているが、管理者特権で救済できてしまう”ことで起きる典型例です。
根本対処は、Everyoneに広く許可するのではなく、管理専用グループや部門グループに対して最小権限を明示的に付与し、継承・所有者・Denyを含めた権限設計を整備することです。続行ボタンを押す運用から脱却し、権限が“勝手に増えない”状態を作ることで、セキュリティと運用の両方が安定します。
コメント