Schlagwort: ActiveDirectory

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

Verschiebung von VM in ActiveDirectory OU scheitert

Eine der Stärken von VDI Lösungen ist die schnelle Bereitstellung von VMs und deren automatische Registrierung im ActiveDirectory. Der hier beschriebene Fall bezieht sich auf ZeroClient VMs (ehemals Panologic), trifft aber auch auf andere Lösungen wie VMware Horizon View, oder Citrix XenDesktop zu.

Autodeployment

Erstellt man VMs mittels Autodeploy, kann man diese dabei in eine entsprechende OU des Active-Directory verschieben lassen. Im Fall einer Panologic Umgebung funktionierte dies lange Zeit problemlos. Nach Neugestaltung der OU wurden VMs aber nicht mehr in der richtigen OU abgelegt, sondern landeten in der OU “Computers”. Grund hierfür waren fehlende Rechte auf die OU für das Dienstkonto, welches die Verteilung erledigt.

PanoOUPermission01Folgende Rechte müssen gesetzt werden:

PanoOUPermission02Wird die Verteilung im Kontext des Domänen Admins ausgeführt (nicht empfohlen), so tritt das Problen natürlich nicht zu Tage. Hier wurde korrekterweise ein eigenständiges Dienstkonto für den Panomanager verwendet. Dieses hatte aber keine Berechtigung zur Objekterstellung in der Ziel-OU.

Veröffentlicht am

vCenter ADWS Error 1209

Nach dem Update von vCenter auf Version 5 kann es zu zahlreichen Einträgen im Ereignisprotokoll von Windows Server 2008 R2 kommen. Im Minutenabstand erscheinen ADWS (Active Directory Web Service) Fehler mit der Nummer 1209.

Englisches System:

Active Directory Web Services encountered an error while reading the settings for the specified Active Directory Lightweight Directory Services instance. Active Directory Web Services will retry this operation periodically. In the mean time, this instance will be ignored.

Deutsches System:

Fehler von Active Directory-Webdiensten beim Lesen der Einstellungen für die angegebene Active Directory Lightweight Directory Services-Instanz. Von den Active Directory-Webdiensten wird in regelmäßigen Abständen erneut versucht, diesen Vorgang auszuführen. In der Zwischenzeit wird diese Instanz ignoriert. „vCenter ADWS Error 1209“ weiterlesen

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