Windows Server 2025 / Berechtigungen für Abteilungsfreigaben planen

Abteilungsfreigaben lassen sich leichter verwalten, wenn Benutzer einer fachlichen Gruppe angehören, diese Gruppe Mitglied einer Ressourcen-Berechtigungsgruppe ist und die Ordnerrechte an Letztere vergeben werden. Im Labor trennen wir Sales (Vertrieb) und Support. Wir prüfen sowohl erlaubte Änderungen in der eigenen Abteilung als auch verweigerten Zugriff auf die andere.

Trennen Sie Konten, fachliche Gruppen und Ressourcengruppen

Für eine einzelne Domäne steht AGDLP für Accounts → Global groups → Domain Local groups → Permissions: Konten, globale Gruppen, domänenlokale Gruppen und Berechtigungen. Das ist ein Ausgangsmuster und nicht die einzig mögliche Architektur. Die Active-Directory-Gruppenbereiche erlauben die Verschachtelung globaler in domänenlokale Gruppen. Domänenlokale Gruppen gehören zum Verzeichnis und sind keine lokalen Gruppen des Computers FS1.

Verwenden Sie den Domänenmitgliedsserver FS1 mit einem Datenvolume des Dateisystems NTFS (New Technology File System). Die Übung zu SMB- und NTFS-Rechten erläutert die beiden Berechtigungsebenen; SMB steht für Server Message Block. Prüfen Sie vor dem Erstellen von D:\Shares\Sales und D:\Shares\Support, ob Ordner oder Freigabenamen bereits verwendet werden. Erstellen Sie ausschließlich neue, leere Laborordner. Alle Objektbezeichnungen der Tabelle sind wörtliche Namen: Übersetzen Sie Sales, Support und die Gruppennamen nicht.

Erstellen Sie Gruppen und normale Testkonten

1. Öffnen Sie in Active Directory-Benutzer und -Computer Lab → LabGroups. Erstellen Sie über Neu → Gruppe die vier Gruppen der Tabelle: GG mit dem Bereich Global, DL mit dem Bereich Domänenlokal. Wählen Sie jeweils Sicherheit statt Verteiler und behalten Sie die Namen exakt bei.
2. Erstellen Sie unter Lab → LabUsers die Konten sales.user1 und support.user1 mit unterschiedlichen Anfangskennwörtern gemäß der wirksamen Kennwortrichtlinie. Ist eine Änderung bei der ersten Anmeldung erforderlich, führen Sie diese bei der Anmeldung auf CLIENT1 vor dem Freigabetest aus.
3. Öffnen Sie in den Eigenschaften der globalen Gruppe Mitglieder → Hinzufügen. Ordnen Sie sales.user1 für diese Übung nur GG_Sales und support.user1 nur GG_Support als fachliche Mitgliedschaft zu.
4. Fügen Sie in Mitglieder von DL_FS_Sales_Modify die Gruppe GG_Sales und in DL_FS_Support_Modify die Gruppe GG_Support ein. Die domänenlokale Gruppe enthält damit die globale Gruppe, nicht umgekehrt.
5. Prüfen Sie, dass keines der Testkonten Administrator ist oder direkt beziehungsweise indirekt einer Gruppe der anderen Abteilung angehört. Entfernen Sie keine Standardgruppen, ohne deren Funktion zu verstehen.

Beachten Sie die Erstellungs- und Bereichsparameter von New-ADGroup. Für den grafischen Ablauf benötigen Sie Active Directory-Benutzer und -Computer auf DC1 oder einem Rechner mit Remoteserver-Verwaltungstools sowie Rechte an den Labor-Organisationseinheiten. Führen Sie die folgenden Abfragen in einer PowerShell mit verfügbarem ActiveDirectory-Modul aus. Bei einem Abteilungswechsel ändern Sie normalerweise fachliche Gruppenmitgliedschaften, statt jeden Benutzer in sämtliche Zugriffssteuerungslisten (Access Control Lists, ACLs) der Ordner einzutragen.

Get-ADGroupMember 'GG_Sales'
Get-ADGroupMember 'DL_FS_Sales_Modify'
Get-ADGroupMember 'GG_Support'
Get-ADGroupMember 'DL_FS_Support_Modify'

Ohne -Recursive zeigt Get-ADGroupMember direkte Mitglieder: In GG_Sales muss sales.user1 stehen, in DL_FS_Sales_Modify die Gruppe GG_Sales. Für Support gilt dasselbe Muster. Dass die Ressourcengruppe die globale Gruppe statt einer aufgelösten Benutzerliste ausgibt, ist das erwartete Ergebnis. Prüfen Sie vor dem Zugriffstest auch indirekte Mitgliedschaften.

Vergeben Sie NTFS-Änderungsrechte an die Ressourcengruppen

1. Öffnen Sie auf FS1 die Eigenschaften von D:\Shares\Sales → Sicherheit → Erweitert. Dokumentieren Sie Einträge und Geltungsbereiche vor jeder Änderung.
2. Deaktivieren Sie nur an diesem neuen, leeren Ordner die Vererbung und wandeln Sie geerbte Berechtigungen in explizite Einträge um. Behalten Sie benötigten Vollzugriff für SYSTEM und Administratoren. Das Umwandeln entfernt breite Zulassen-Einträge nicht.
3. Prüfen Sie Benutzer, Authentifizierte Benutzer, Jeder und andere allgemeine Gruppen. Entfernen Sie unnötige Berechtigungen an diesem Ordner, auch Leserechte, die Zugriff auf die andere Abteilung ermöglichen würden.
4. Erlauben Sie AD\DL_FS_Sales_Modify Ändern mit dem Geltungsbereich Diesen Ordner, Unterordner und Dateien. Tragen Sie sales.user1 nicht direkt in die ACL ein.
5. Wiederholen Sie dies an D:\Shares\Support mit AD\DL_FS_Support_Modify. Jeder Ordner soll neben den notwendigen Verwaltungsrechten ausschließlich seine passende Ressourcengruppe enthalten.

Ändern erlaubt gewöhnliche Inhaltsänderungen und ist nicht mit Vollzugriff oder umfassender Berechtigungsverwaltung gleichzusetzen. Zulassen-Rechte aus mehreren Gruppen können sich ergänzen. Richten Sie zunächst die erforderlichen positiven Berechtigungen ein und entfernen Sie unnötige breite Zugriffsrechte an diesen neuen Ordnern; beginnen Sie nicht mit einer Verweigerung für die andere Abteilung.

Konfigurieren Sie Freigaben und den Servernamen

1. Öffnen Sie die Eigenschaften von D:\Shares\Sales → Freigabe → Erweiterte Freigabe und geben Sie den Ordner unter dem unveränderten Namen Sales frei.
2. Erlauben Sie unter Berechtigungen der Gruppe AD\DL_FS_Sales_Modify Ändern und behalten Sie erforderliche Verwaltungsrechte. Entfernen Sie unnötige breite Zugriffsrechte für andere Benutzer; geben Sie nicht der gesamten Domäne Vollzugriff.
3. Geben Sie D:\Shares\Support als Support frei und erlauben Sie AD\DL_FS_Support_Modify Ändern. Prüfen Sie die Standardwerte und speichern Sie beide Freigaben getrennt.
4. Fragen Sie in PowerShell auf FS1 mit den folgenden Befehlen Pfade und Rechte ab. Name und Path müssen zur Tabelle passen. Neben den vorgesehenen Verwaltungseinträgen muss jede Ressourcengruppe Allow und Change nur an ihrer eigenen Freigabe besitzen.

Get-SmbShare -Name Sales,Support | Select-Object Name,Path
Get-SmbShareAccess -Name Sales
Get-SmbShareAccess -Name Support

Verwenden Sie \\fs1.ad.example.test\Sales und \\fs1.ad.example.test\Support. Bleiben Sie bei demselben Servernamen und mischen Sie während des Tests keine IP-Adressen oder improvisierten Aliase. Die zugriffsbasierte Aufzählung kann Einträge ausblenden; ein unsichtbarer Name beweist aber keine Zugriffsverweigerung. Testen Sie deshalb auch den direkten Pfad zur anderen Freigabe.

Prüfen Sie beide Identitäten und den Zugriff auf die andere Abteilung

Melden Sie sich auf CLIENT1 ab und neu als sales.user1 an. Prüfen Sie whoami, whoami /groups und vorhandene SMB-Verbindungen, damit keine Administratorsitzung wiederverwendet wird. Erstellen Sie in Sales eine Testdatei, bearbeiten und lesen Sie diese erneut und löschen Sie sie. Versuchen Sie danach, Support direkt zu öffnen: Der Zugriff muss verweigert werden. Wiederholen Sie den Test umgekehrt mit support.user1 und dokumentieren Sie beide Identitäten. Bei Abweichungen prüfen Sie Freigaberechte, NTFS-ACLs, Vererbung, Mitgliedschaften und tatsächliche Anmeldeinformationen getrennt; überdecken Sie den Fehler nicht mit Vollzugriff.

Für einen kontrollierten Wechsel dokumentieren Sie die Ausgangsmitgliedschaften von sales.user1, entfernen nur dieses Konto aus GG_Sales und fügen es zu GG_Support hinzu. Lassen Sie ACLs und andere Konten unverändert. Nach vollständiger Ab- und Anmeldung muss es unter den Laborbedingungen in Support arbeiten können und den Zugriff auf Sales verlieren. Stellen Sie danach die ursprünglichen Mitgliedschaften exakt wieder her, melden Sie das Konto neu an und prüfen Sie den Ausgangszustand erneut. Ermitteln Sie vor einer Bereinigung alle Berechtigungsverweise: Wer Gruppen zuerst löscht, kann nicht mehr auflösbare Sicherheitskennungen (Security Identifiers, SIDs) in ACLs hinterlassen. Bewahren Sie Ordner, Freigaben und Aufzeichnungen für die spätere Übung zum verteilten Dateisystem DFS auf.