デュアルブートWin7のNTFSアクセス許可には、どの組み込みWindowsグループを使用する必要がありますか?


4

一部のコンピューターでまだデュアルブートを使用しているため、2つのWindows 7インストールを実行しています。ほとんどのデータは、両方のインストールで使用される個別のハードドライブ上のパーティションにあります。

特定のファイルではNTFSアクセス許可を設定する必要がありますが、ユーザーアカウントまたはカスタムWindowsグループを使用してこれを行うと、1つのインストールで正常に動作します。2番目のインストールを起動すると、ACLのエントリは最初のインストールのアカウントに固有であるため(およびセキュリティダイアログで「不明」と表示されるため)、ユーザーはファイルにアクセスできません。

これを回避するには、組み込みのWindowsグループのいずれかを使用できます。それらのSIDは、Windowsのすべてのインストールで同じです。

問題は、どの組み込みグループを使用するかです。ユーザーに追加の許可をできるだけ少なくしたい:

Administrators                  S-1-5-32-544
Backup Operators                S-1-5-32-551
Cryptographic Operators         S-1-5-32-569
Distributed COM Users           S-1-5-32-562
Event Log Readers               S-1-5-32-573
Guests                          S-1-5-32-546
IIS_IUSRS                       S-1-5-32-568
Network Configuration Operators S-1-5-32-556
Performance Log Users           S-1-5-32-559
Performance Monitor Users       S-1-5-32-558
Power Users                     S-1-5-32-547
Remote Desktop Users            S-1-5-32-555
Replicator                      S-1-5-32-552
Users                           S-1-5-32-545

これらのグループのアカウントには強力なアクセス許可があるため、管理者、バックアップオペレーター、またはパワーユーザーを使用したくありません。残りのどれが最も「強力」ではありませんか?

また、「ゲスト」はファイルにアクセスできないため、使用できません。

すべての通常のユーザーがそのグループに属しているが、すべてのユーザーが問題のファイルにアクセスできる必要があるわけではないため、「ユーザー」も使用できません。


これらのコンピューターが同じドメインに属している場合、グループのポリシーに基づいてこれらのファイルにアクセスできるようにするだけで、ドメインにグループを明確に作成できます。ドメインに接続していない場合、詳細情報が必要です。それらのユーザーのほとんどは実際には使用すべきではありません。
ラムハウンド

ドメイン内ではありません。そうでなければ、ドメイングループを使用できます。スタンドアロンのマシン。必要な情報は何ですか?
ピーターハーンドルフ

回答:


3

1ワード。ユーザー。

ユーザーは基本的に、そのマシンによってローカルで認証されるすべての人です。


はい、それは明らかです。私はそれが選択肢ではない理由を言ったはずです。(質問を編集しました)。「ユーザー」グループに所属する必要があるユーザーが複数いますが、すべてのユーザーが保護するファイルにアクセスできる必要はありません。
ピーターハーンドルフ

あるワークステーションから別のワークステーションに「ACL」を使用したい場合は、各OS間で共通のSIDを保持するために、何らかの中央機関(ドメインコントローラー)が必要です。ワークステーションでSIDを変更するためのトリックがありますが、通常は良い考えではありません。
TheCompWiz

technet.microsoft.com/en-us/sysinternals/bb897418 <--- sidを新しいものに変更するように設計されていますが、このツールでは特定の値に設定できません。下の方に、ツールの仕組みが表示されます...そして、これらの指示を使用して、あるSIDを別のOSにコピーできます。次のトリックは、一致するSIDを持つグループを作成することです。
TheCompWiz

1

Windows Vista以降では、「Power Users」グループはほとんどすべての権限を失い、そのメンバーは基本的に「users」グループのメンバーと同じくらい強力です。

そのため、Power Usersグループは、指定された要件の適切な候補です。

また、「レプリケーター」グループには追加のユーザー権限はなく、AFAIKにはセキュリティで保護されたオブジェクトに対する権限はありません。これは、Windows NT時代のレガシーグループです。

サーバーを使用している場合、「Print Operators」グループは別の候補です。

編集: 「Power Users」グループと「Print Operators」グループの両方がこの目的では機能しないことがわかりました。ユーザーがこれらのグループのメンバーであり、グループがリソースへの書き込み許可を持っている場合でも、ユーザーはリソースへの書き込みアクセス権を持ちません。

管理者グループと同様に、これらのグループは特別であり、ユーザーがグループに属している場合、ログオン時に分割トークンを取得します。このグループメンバーシップを介して獲得したアクセス許可は、彼の標準ユーザートークンに含まれていないため、リソースへのアクセス権はありません。

これを確認するには、次のように入力します

whoami /groups

「Power Users」グループには次の属性があります。

Group used for deny only

「リモートデスクトップユーザー」グループにはこれはありませんが、ユーザーがRDPを介してログオンできるようにする副作用があります。このために使用できる唯一のグループはレプリケーターグループです


0

非常に実験的なアプローチの1つは、両方のWindowsインストールで同じユーザーデータベース(SAM)を使用することです。

\Windows\System32\config\SAMインストール1のSAMファイル()をインストール2 にコピーできた場合、ユーザーはSIDレベルまで同一です。

同様のアプローチは、各インストールでグループを作成し、1つのインストールのSAMファイルを編集して、他のインストールで使用されるSIDのSIDを変更することです。パスワードリセットツールがSAMを変更すると、これが可能な方法になる可能性があります。

私は自分でこれを試したことはありません-したがって、そのようなアプローチを試す前に、システムの完全なバックアップを必ず取ってください...


これは大きなハックです。組み込みグループの1つを使用する実用的なアプローチの何がそんなに悪いのでしょうか。間違いなく機能します。副作用を最小限に抑えたいだけです。
ピーターハーンドルフ

@PeterHahndorf-これらの他のユーザーグループはいずれも、毎日のユーザーが使用するように設計されていないためです。ファイルへのアクセスを必要とする少数のユーザー向けに独自のグループを作成してみてください。Power Usersグループは、まさにこの目的のために設計されています。
ラムハウンド

@Ramhound-独自のグループの作成は機能しません。これは、インストールごとにSIDが異なるためです。「パワーユーザー」を使用したくないのは、ユーザーにあまりにも多くのパワーを与えるためです。
ピーターハーンドルフ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.