Welche integrierte Windows-Gruppe sollte ich für NTFS-Berechtigungen beim Dual-Boot von Win7 verwenden?

Welche integrierte Windows-Gruppe sollte ich für NTFS-Berechtigungen beim Dual-Boot von Win7 verwenden?

Auf einigen meiner Computer verwende ich immer noch Dual-Boot, d. h. ich habe zwei Windows 7-Installationen laufen. Die meisten Daten liegen auf einer Partition auf einer separaten Festplatte, die von beiden Installationen verwendet wird.

Für bestimmte Dateien muss ich NTFS-Berechtigungen festlegen. Wenn ich dies über ein Benutzerkonto oder eine benutzerdefinierte Windows-Gruppe mache, funktioniert es bei einer Installation problemlos. Beim Booten in die zweite Installation hat der Benutzer keinen Zugriff auf die Dateien, da die Einträge in den ACLs spezifisch für das Konto der ersten Installation sind (und im Sicherheitsdialog als „unbekannt“ angezeigt werden).

Um dies zu umgehen, könnte ich eine der integrierten Windows-Gruppen verwenden. Ihre Seiten sind bei allen Windows-Installationen gleich.

Die Frage ist, welche der integrierten Gruppen verwendet werden soll. Ich möchte dem Benutzer so wenig zusätzliche Berechtigungen wie möglich erteilen:

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

Ich möchte keine Administratoren, Backup-Operatoren oder Power-User verwenden, da die Konten in diesen Gruppen über umfassende Berechtigungen verfügen. Welche der übrigen Gruppen ist am wenigsten „umfassend“?

Ich kann auch keine „Gäste“ verwenden, da diese keinen Zugriff auf die Dateien haben sollten.

Auch „Benutzer“ kann ich nicht verwenden, da jeder normale Benutzer in dieser Gruppe ist, aber nicht jeder Benutzer Zugriff auf die betreffenden Dateien haben soll.

Antwort1

1 Wort. Benutzer.

Als Benutzer gilt grundsätzlich jeder, der von diesem Computer lokal authentifiziert werden kann.

Antwort2

Es scheint, dass in Windows Vista und höher die Gruppe der „Power Users“ nahezu alle ihre Befugnisse verloren hat und ihre Mitglieder im Wesentlichen genauso viel Macht haben wie die Mitglieder der Gruppe der „Benutzer“.

Daher ist die Gruppe der Power-User ein guter Kandidat für die gegebene Anforderung.

Außerdem hat die Gruppe „Replicator“ keine zusätzlichen Benutzerrechte und meines Wissens nach auch keine Berechtigungen für sichere Objekte. Es handelt sich um eine Legacy-Gruppe aus der Zeit von Windows NT.

Wenn Sie Server verwenden, ist die Gruppe „Druckoperatoren“ ein weiterer Kandidat.

Bearbeiten: Es stellt sich heraus, dass weder die Gruppe „Power Users“ noch die Gruppe „Print Operators“ für diesen Zweck geeignet sind. Selbst wenn ein Benutzer Mitglied dieser Gruppen ist und die Gruppen beispielsweise Schreibberechtigungen für eine Ressource haben, hat der Benutzer keinen Schreibzugriff auf die Ressource.

Wie die Administratorengruppe sind diese Gruppen speziell und wenn ein Benutzer in der Gruppe ist, erhält er bei der Anmeldung ein Split-Token. Die durch diese Gruppenmitgliedschaft erworbenen Berechtigungen sind nicht in seinem Standard-Benutzertoken enthalten und daher hat er keinen Zugriff auf die Ressource.

Sie können dies sehen, indem Sie Folgendes eingeben:

whoami /groups

Die Gruppe „Power Users“ verfügt über folgendes Attribut:

Group used for deny only

Die Gruppe „Remote-Desktop-Benutzer“ verfügt nicht über diese Funktion, hat aber den Nebeneffekt, dass der Benutzer sich über RDP anmelden kann. Die einzige Gruppe, die hierfür verwendet werden kann, ist dieReplikatorGruppe

Antwort3

Ein sehr experimenteller Ansatz wäre, beide Windows-Installationen dieselbe Benutzerdatenbank (SAM) verwenden zu lassen.

Wenn es Ihnen gelingen würde, die SAM-Datei ( \Windows\System32\config\SAM) von Installation 1 in Installation 2 zu kopieren, wären die Benutzer bis auf die SID-Ebene identisch.

Ein ähnlicher Ansatz wäre, bei jeder Installation eine Gruppe zu erstellen und dann zu versuchen, die SAM-Datei einer Installation zu bearbeiten und deren SID in die von der anderen Installation verwendete zu ändern. Da Tools zum Zurücksetzen von Passwörtern die SAM ändern, könnte dies ein möglicher Weg sein.

Ich habe das selbst nie versucht. Stellen Sie daher vor dem Ausprobieren solcher Ansätze sicher, dass Sie über eine vollständige Sicherung Ihres Systems verfügen …

verwandte Informationen