Schlagwort: ACL

Veröffentlicht am

HP 5130 – Zugriff auf WEB-GUI einschränken

Der HP 5130 ist ein Layer 3 Switch und als solcher hat er nicht nur Switch-, sondern auch Routingfähigkeiten. Die einfachste Art des Routings erfolgt intern zwischen definierten VLANs. Sobald dem VLAN eine IP Adresse auf dem Switch definiert wurde, erhält dieser automatisch einen Eintrag in der Routingtabelle, welcher die Kommunikation zwischen den Subnetzen bzw. VLANs ermöglicht.

Was zunächst sehr komfortabel ist, mag aber aus Sicherheitsaspekten nicht unbedingt gewünscht sein. So erreicht man aus jedem VLAN die Management GUI des Switches oder die Konsole per SSH.

„HP 5130 – Zugriff auf WEB-GUI einschränken“ weiterlesen

Veröffentlicht am

vCenter SSO nested groups

Das Modul vSphere Single-Signon (SSO) ist fester Bestandteil der vCenter Installation seit Version 5.1. Es ist ein zentraler Bestandteil und wird daher noch vor dem vCenter Dienst installiert. Justin King hat zum Thema eine sehr gute vierteilige Einführung im vSphere Blog (vmware) geschrieben. Updates von vCenter innerhalb der Version 5.1 hatten schon so einige Tücken, aber beim Upgrade auf Version 5.5 kann es je nach Strukturierung der Benutzergruppen zu Aussperrungen kommen.

Ausgesperrt

Beim Upgrade eines vCenter Servers von Version 5.1 auf 5.5 erlebte ich eine unangenehme Überraschung. Sämtliche vSphere Admins hatten nach dem Upgrade keinen Zugriff mehr auf den Cluster. Alle Benutzer waren Mitglieder der lokalen Admingruppe und als solche hätten sie vollen Zugriff auf vCenter haben müssen. Das Gegenteil war der Fall.

Fehlersuche

Fügte man einen Domänen Benutzer diskret hinzu, so erhielt er Zugriff. Als Mitglied einer Gruppe im Active-Directory konnten dem Benutzer ebenfalls Rechte zugeteilt werden. Der selbe Benutzer als Mitglied einer lokalen Gruppe erhielt keinen Zugriff. Offensichtlich kommt Single-Signon neuerdings nicht mehr mit geschachtelten Domänen Benutzern in lokalen Gruppen zurecht. Nach kurzer Suche wurde dies durch einen Artikel in den vmware-blogs bestätigt. Unter SSO Version 5.1 war dies noch problemlos möglich.

Vorsorge

Meine Empfehlung ist daher, vor dem Upgrade auf Version 5.5 zu kontrollieren, ob die Nutzerrechte über reine Active Directory Gruppen definiert sind. D.h. globale Gruppen mit ADS Usern.

Benutzer im Beispiel 1 erhalten Zugriff. Die selben Benutzer in einer lokalen Gruppe (Beispiel 2) erhalten keinen Zugriff. Das Problem sind hierbei nicht die lokalen Gruppen, sondern deren Verschachtelung mit Domänenbenutzern.

  1. vSphere-Admins (Sicherheitsgruppe, Domäne)
    • Domain\User1
    • Domain\User2
  2. Administratoren (Sicherheitsgruppe, lokal)
    • Domain\User1
    • Domain\User2

Links

 

Veröffentlicht am

NTFS Sicherheit: Ersteller Besitzer Objekt

Ein Verzeichnis soll für zwei Benutzergruppen zugänglich sein. Gruppe “Edit” soll lesen, schreiben und verändern dürfen. Die zweite Gruppe “Public” soll nur lesen dürfen, aber keine Daten verändern. Klingt einfach – und ist es eigentlich auch. Dennoch zeigt der Ordner ein eigenwilliges Verhalten: Jeder in der Gruppe Public konnte Dateien erstellen und diese auch ändern. Ursache war, daß es neben den Gruppen Public und Edit noch die Gruppe “Ersteller Besitzer” gab.

Die Gruppe “Ersteller Besitzer” kann problemlos entfernt werden. Sobald dies erfolgt ist, greifen die Zugriffsrechte wie oben geplant.

Links

 

Veröffentlicht am

Robocopy Error 5 – Access denied

Bei der Spiegelung eines Volumes von Fileserver-A nach Fileserver-B mit Robocopy trat ein erstaunliches Phänomen auf. Der erste Kopiervorgang verlief problemlos.

robocopy \\Fileserver-A\Share1 d:\ /MIR /SEC /DCOPY:T /R:1 /W:1

Nun sollte einige Zeit später der zweite Durchgang die Veränderungen kopieren. Erneut führte ich den Befehl oben aus und wurde mit folgender Fehlermeldung konfrontiert:

ERROR 5 (0x00000005) Copying NTFS Security to Destination Directory <directoryname> Access is denied

Es kann sein, daß das Konto, welches Robocopy ausführt, keine Schreibrechte auf die Datei oder den Ordner hat. Eine Aktualisierung ist somit nicht möglich und erzeugt den Fehler. Hätte ich die Daten ohne ACL kopiert, wäre es kein Problem.

Abhilfe

Es ist eine gute Methode, zunächst nur die Daten ohne Sicherheitsinformationen zu kopieren. Diesen Befehl iteriert man, bis die Daten ganz aktuell sind und nicht mehr durch User verändert werden können.

robocopy <SOURCE> <TARGET> /MIR /DCOPY:T /R:1 /W:1

Im letzten Durchgang überträgt man die Rechte auf Dateien und Ordner.

robocopy <SOURCE> <TARGET> /MIR /SEC /SECFIX /DCOPY:T /R:1 /W:1

Links