Windows Serverの共有フォルダーを、別ワークグループにある別サーバーのローカルユーザーへ開放したいのに、権限追加画面に相手側ユーザーが出てこない——そんな場面は意外と多いです。原因は「操作ミス」ではなく仕組みの問題です。本記事では、できない理由を整理したうえで、現場で破綻しにくい回避策と設定手順、つまずきやすいポイントの潰し込みまでまとめます。
結論：別ワークグループの「相手サーバーのローカルユーザー」はACLに直接追加できない
サーバーA（共有側）の共有フォルダーに対して、サーバーB（別ワークグループ：例 RemoteWG）のローカル管理者アカウント Remote_User を「共有権限」「NTFS権限」に追加したい、という要望はよくあります。しかし、ワークグループが異なる（信頼関係がない）環境では、サーバーBのローカルユーザーをサーバーAのACLに直接追加することはできません。
理由はシンプルで、Windowsのアクセス制御は“名前”ではなくSID（Security Identifier）を基準に動きます。ローカルユーザーのSIDは、そのユーザーが作成されたコンピューターのローカルSAMに属するため、他のワークグループのPC/サーバーからは正しく解決できません。結果として、権限追加（ユーザー選択）画面では「ドメインユーザー」や「サーバーAのローカルアカウント」しか候補に出てこない、という挙動になります。
| 追加したい主体 | 共有側サーバーAで識別できる？ | 理由（かみ砕き） |
|---|---|---|
| サーバーAのローカルユーザー / ローカルグループ | できる | サーバーAのSAMに存在し、SIDが解決できる |
| 同一ドメインのドメインユーザー / ドメイングループ | できる | ADにより名前→SIDが解決でき、信頼経路がある |
| 別ワークグループのサーバーBのローカルユーザー | できない | 信頼関係がなく、SIDの解決ができない（同名でも別物） |
現実的な回避策：共有側に“アクセス用ローカルアカウント”を用意する
ワークグループを維持したまま進めるなら、現場で安定しやすい方針は次の通りです。
- 共有側サーバーAに、アクセス専用のローカルアカウント（例：Remote_User）を作成
- そのアカウント（またはローカルグループ）に、共有権限とNTFS権限の両方で必要最小限を付与
- 接続元サーバーBにも同じユーザー名・同じパスワードのローカルアカウントを作ると、パススルー認証でスムーズに通りやすい
ポイントは「サーバーAが理解できる主体（＝サーバーA上のローカルアカウント/グループ）」に権限を付与し、接続時の認証でその主体としてログオンさせる、という組み立てです。
共有権限とNTFS権限の基本：最終的には“より厳しい方”が効く
共有フォルダーのアクセス権は、主に共有権限（Share Permission）とNTFS権限（ファイル/フォルダーのセキュリティ）の組み合わせで決まります。両方を設定する必要があり、最終的な有効権限はより制限の強い方になります。
| 項目 | 共有権限 | NTFS権限 |
|---|---|---|
| 適用範囲 | ネットワーク経由のアクセス | ローカル/ネットワーク両方 |
| 設定場所 | 共有のプロパティ（共有タブ等） | フォルダーのプロパティ（セキュリティタブ） |
| 運用の考え方 | “入口のゲート”として最低限にする/または広めにしてNTFSで絞る | 実際の権限設計の中心（推奨） |
たとえば、共有権限が「読み取り」でもNTFSが「変更」でも、結果は読み取りに落ちます。逆に、共有権限が「変更」でもNTFSが「読み取り」なら、結果は読み取りです。トラブル時は、必ず共有権限とNTFS権限の両方を確認してください。
推奨手順：サーバーAにアクセス用ローカルユーザーを作って権限を付与する
設計のすすめ：ユーザー直付けより“ローカルグループ”運用が楽
将来の変更（ユーザー追加/削除、権限見直し）を考えると、フォルダー権限はユーザー直付けよりも、ローカルグループに権限を付けて、ユーザーはグループへ所属させる方が運用が安定します。
| 方式 | メリット | デメリット |
|---|---|---|
| ユーザー直付け | 小規模なら分かりやすい | 人数が増えるほどACLが散らかる |
| ローカルグループ運用 | 権限変更が1か所で済む、棚卸しが容易 | 最初に設計が必要 |
GUIでの設定例（手順の全体像）
- サーバーAでローカルユーザー Remote_User（または任意名）を作成
- （推奨）サーバーAでローカルグループ（例：Share_Remote_RW）を作成し、Remote_Userを所属させる
- 共有フォルダーの共有権限に、Share_Remote_RW（またはRemote_User）を追加
- 共有フォルダーのNTFS権限に、Share_Remote_RW（またはRemote_User）を追加
コマンドでの設定例（再現性を重視する場合）
GUI運用でも問題ありませんが、設定を統一したい・手順書を固めたい場合はコマンドが便利です。以下は一例です（フォルダーや共有名は環境に合わせて変更してください）。
ローカルユーザー作成（例）
REM サーバーAで実行（管理者のコマンドプロンプト）
net user Remote_User StrongPasswordHere /add
REM （任意）パスワード期限のポリシーは環境方針に合わせて運用
REM net user Remote_User /passwordchg:yesローカルグループ作成＋ユーザー追加（推奨）
net localgroup Share_Remote_RW /add
net localgroup Share_Remote_RW Remote_User /add共有作成（SMB共有）
REM 既存共有がある場合は、共有権限の追加を行う
REM 新規作成する場合の例（PowerShell）
PowerShell -NoProfile -Command "New-SmbShare -Name 'Share' -Path 'D:\Share' -ChangeAccess 'ServerA\Share_Remote_RW' -FullAccess 'Administrators'"
REM 共有権限の確認（PowerShell）
PowerShell -NoProfile -Command "Get-SmbShareAccess -Name 'Share'"NTFS権限付与（icacls）
REM 変更(M)を付与：フォルダー/ファイルに継承（OI)(CI)
icacls "D:\Share" /grant "ServerA\Share_Remote_RW:(OI)(CI)M"
REM 権限の確認
icacls "D:\Share"共有権限とNTFS権限はどちらも重要です。特に「共有権限は付けたのに入れない」「NTFSはOKなのにネットワーク経由だけ拒否される」といったケースは、片方の設定漏れや想定外の制限が原因になりがちです。
接続元サーバーBからアクセスする方法
パススルー認証：同名・同パスワードのローカルアカウントを両側に作る
ワークグループ環境でよく使われるのがパススルー認証です。考え方は単純で、サーバーBでログオンしているユーザー名/パスワードと、サーバーAに存在するローカルユーザー名/パスワードが一致していれば、サーバーA側は「自分のローカルユーザーとして」認証できます。
- サーバーA：Remote_User（アクセス許可を付けた主体）
- サーバーB：Remote_User（同名・同パスワードで作成）
この状態でサーバーBのセッションがRemote_Userで動いていると、共有アクセスがスムーズになります。
明示的に資格情報を指定する：net use（推奨の切り分け手段）
サーバーB側に同名ユーザーを作らない場合でも、接続時にサーバーAの資格情報を明示すれば接続できることがあります。トラブルシュートでも必須級のコマンドです。
REM 共有へ接続（資格情報を明示）
net use \\ServerA\Share /user:ServerA\Remote_User StrongPasswordHere
REM ドライブレターに割り当てる例
net use Z: \\ServerA\Share /user:ServerA\Remote_User StrongPasswordHere /persistent:no資格情報をWindowsに覚えさせたい場合は、資格情報マネージャー（GUI）か cmdkey を使います。
REM 資格情報を登録（ServerAに対してRemote_Userで接続する想定）
cmdkey /add:ServerA /user:ServerA\Remote_User /pass:StrongPasswordHere
REM 登録済みの確認
cmdkey /list同じ宛先に別ユーザーで繋げない問題（定番の詰まりポイント）
Windowsは同一セッション内で「同じサーバー（ServerA）に対して、複数のユーザー資格情報で同時接続」しようとすると拒否することがあります。エラー文としては次のような形が多いです。
- 「同じユーザー名で複数の接続を行うことはできません」
- 「複数のユーザー名でサーバーまたは共有リソースへ接続されています」
この場合は、いったん既存の接続を切ってからやり直します。
REM 既存の接続を確認
net use
REM ServerAへの接続を削除（パス指定）
net use \\ServerA\Share /delete
REM まとめて削除（影響範囲が広いので注意）
net use * /deleteよくある落とし穴：権限設定が正しくても“通信・認証・名前解決”で詰まる
権限を付けたのにアクセスできない場合、原因は「ACL」だけではありません。ワークグループ間の共有アクセスでは、次の層で詰まりやすいです。
| 層 | 典型症状 | チェック/対処 |
|---|---|---|
| 名前解決 | ServerAが見つからない、接続が不安定 | DNS登録、hosts追記、まずはIPで試す（\\10.0.0.10\Share） |
| ファイアウォール | タイムアウト、ネットワークパスが見つからない | TCP 445（SMB）許可、ファイルとプリンター共有の規則を確認 |
| 認証（資格情報） | 資格情報が違う、アクセス拒否 | net useで明示、既存接続を削除、資格情報キャッシュを確認 |
| 権限（共有/NTFS） | 接続はできるがフォルダーを開けない | 共有権限とNTFS権限を両方チェック（より厳しい方が有効） |
名前解決の現実：ワークグループ同士は“見つからない”前提で設計する
ワークグループ環境では、DNSやNetBIOS名解決が整っていないと「名前で共有に繋ぐ」ことが不安定になります。運用としては、次のどれかに寄せるとトラブルが減ります。
- DNSで ServerA が引けるようにする（社内DNS、ルータのDNS等）
- サーバーBの hosts に固定で登録する（小規模向け）
- 切り分け時は IPアドレスで接続して名前解決問題を除外する
ファイアウォール：SMBはTCP 445が基本
共有が「開いているのに見えない」「資格情報画面すら出ない」場合、ファイアウォールでSMBが遮断されていることがよくあります。サーバーA側で「ファイルとプリンターの共有」の受信規則、ネットワークプロファイル（ドメイン/プライベート/パブリック）を確認してください。
“ローカル管理者で共有アクセス”が不安定になりやすい理由
実務的な注意として、共有アクセスにローカル管理者を使うと、セキュリティ設定（UACのリモート制限など）や監査設計の都合で、期待した権限にならないことがあります。特に「Administratorsグループに権限があるから大丈夫」と思っていると、ネットワーク経由のトークンが制限されて管理者として扱われないケースが出ます。
そのため、共有アクセスは次の方針が安全です。
- 専用の標準ユーザー（最小権限）を作り、そのユーザー/グループに明示的に権限を付ける
- ローカル管理者アカウントを日常的なファイル共有アクセスに流用しない
トラブルシュート：確認すべきポイントを“順番”で潰す
原因を最短で切り分けるには、上から順番に確認するのがコツです。
共有側（サーバーA）の確認
- 共有は存在するか（共有名、パス）
- 共有権限に Remote_User（またはShare_Remote_RW）が入っているか
- NTFS権限に Remote_User（またはShare_Remote_RW）が入っているか
- （必要に応じて）アクセスログやセキュリティログで拒否理由が出ていないか
PowerShellが使える環境なら、共有権限の確認はこれが早いです。
PowerShell -NoProfile -Command "Get-SmbShareAccess -Name 'Share'"接続元（サーバーB）の確認
- 名前解決：ServerAに ping が通る/名前が引ける
- 通信：TCP 445が到達できる（FW/ネットワーク経路）
- 資格情報：net useで明示して通るか
- 既存接続：net use で別資格情報が残っていないか
切り分けとして最も強いのは、「いったん既存接続を消して、資格情報を明示して接続する」ことです。
net use * /delete
net use \\ServerA\Share /user:ServerA\Remote_User StrongPasswordHere権限の見落としを防ぐコツ
権限周りは“どこで拒否されているか”を意識すると迷子になりません。
- 共有に入る前に拒否：共有権限、資格情報、既存接続、FW
- 共有には入れるがフォルダーが開けない：NTFS権限（継承/拒否ACE/上位フォルダー）
- 特定のサブフォルダーだけ開けない：サブフォルダーの固有ACL、継承切り、拒否ACE
運用の選択肢：ワークグループで頑張るか、認証基盤を揃えるか
短期的に「とにかく通したい」ならローカルアカウント運用で解決できますが、台数や担当者が増えると、パスワード同期・棚卸し・監査が重くなります。長期運用の目線で、選択肢を比較しておくと判断が早くなります。
| 選択肢 | 運用コスト | セキュリティ/監査 | 向いている規模 |
|---|---|---|---|
| 共有側にローカルユーザー作成＋net useで明示 | 中（端末ごとに設定/手順が必要） | ユーザー別に追えるが、資格情報管理が課題 | 小〜中 |
| 同名同パスワードでパススルー認証 | 中〜高（パスワード同期が増える） | 同期ミスが事故要因になりやすい | 小 |
| 同一ドメイン参加（Active Directory） | 低〜中（最初の構築は必要） | 最も管理しやすい（集中管理/監査/グループ運用） | 中〜大 |
もし「この手の共有が増える見込みがある」「担当者が入れ替わる」「監査要件がある」なら、可能な範囲で同一ドメイン参加（AD）や中央認証基盤の利用を検討する価値があります。ローカルアカウントのパスワード同期運用は、仕組みで担保しにくく、属人化しやすいからです。
セキュリティを崩さずに運用するチェックリスト
ワークグループ環境で共有を回す場合でも、最低限ここは押さえると事故が減ります。
- 共有アクセス専用の標準ユーザーを作る（管理者アカウントを流用しない）
- 権限は必要最小限（読み取りのみ、変更可など用途で分ける）
- ユーザー直付けではなく、ローカルグループに権限を付ける
- 共有権限とNTFS権限の両方を管理し、どちらか一方に依存しない
- 資格情報は可能なら資格情報マネージャーで管理し、手入力を減らす
- 定期的に「誰に権限があるか」を棚卸しする（グループ運用だと楽）
まとめ
別ワークグループのサーバーBにあるローカルユーザー（Remote_User）を、共有側サーバーAの共有/NTFS権限に“そのまま”追加できないのは、ワークグループ間に信頼関係がなく、SID解決ができないという仕組み上の制約が原因です。回避策としては、共有側サーバーAにアクセス専用のローカルアカウント（またはローカルグループ）を作り、共有権限とNTFS権限の両方を付与したうえで、接続元からは同名同パスワードのパススルー認証、またはnet useで資格情報を明示して接続するのが現実的です。
台数や運用期間が伸びるほど、ローカルアカウント同期は管理負担が増えます。将来的に拡張する可能性があるなら、Active Directoryなどの中央認証も含めて設計すると、共有運用が一気に安定します。
コメント