0x80070005, Constrainted Delegation

wenn man versucht eine neue VM zu erstellen oder Konfiguration zu ändern kann es vorkommen das man eine Fehlermeldung bekommt, die sagt, das die Aktion fehlgeschlagen ist.

 

The operation failed. Failed to create external configuration store at ‚\\sofs\SOFS-Share2\VM3‘: General access denied error. (0x80070005)
 

 

The operation failed. Failed to create external configuration store at '\\sofs\SOFS-Share2\VM3': General access denied error. (0x80070005)

 

 

 

Berechtigung auf VHDX Files

Die erste Vermutung geht logischerweise in die Rechtevergabe. Schaut man sich diese genau an wird man erstaunt sein, wie Fehler-unanfällig die Rechtevergabe vom System eingerichtet wurde. Folgendes Beispiel zeigt die Funktion innerhalb einer Domänenstruktur. Ein Betrieb ohne Domäne ist mit SMB3 oder auch CSV / Clusterbetrieb nicht unterstützt.

 

NTFS Permission Tab Hyper-V

Dies ist die Standard NTFS Berechtigung eines SOFS mit einer Freigabe auf einem CSV. Wir können für die Berechtigung weder Benutzer noch das System brauchen.

Noch mal zur Erinnerung: Wer Zugriff auf das VHDX File hat, wenn auch nur lesend, hat virtuellen Zutritt zum RZ inkl. einem entsperrten Server!

 

 

Best Practice für NTFS und Share ist Vollzugriff für die Gruppe der Administratoren, die den Hyper-V bzw. Cluster verwalten, sowie das Hyper-V Computerobjekt. Auf dem Share gibt es Vollzugriff für Jeden.

Lässt man wie im oberen Screenshot die lokale Gruppe der Administratoren (2012R2-SOFS1\Administratoren) NTFS seitig stehen, wird man feststellen, das an gleicher Stelle auf  dem anderen SOFS Member im CSV die lokale Gruppe des anderen Servers eingetragen ist, also (2012R2-SOFS2\Administratoren).

Eigentlich sehr gut umgesetzt, aber möchte ich wirklich, dass ein lokaler Admin meines Memberservers Vollzugriff auf die virtuellen Festplatten hat? Dies lässt sich nur bedingt einschränken. Lokal lässt sich der Besitz immer übernehmen, und somit Zugriff auf die VHDX Files. Geht man jetzt davon aus das die lokalen Admins aller Memberserver identische Passwörter haben, hat man durch das auf C$ positionierte CSV auch Vollzugriff auf das File über das Netz! Workaround ist also Zugriff für die lokalen Administratoren entfernen, oder den lokalen Administratoren der SMB3 Server andere Passwörter zu geben, und diesen Zugriff höher einzustufen!

 

Im folgenden Beispiel wurde die erste Variante umgesetzt. Die Vererbung wurde deaktiviert, und alles entfernt, die Gruppe der Domänen-Administratoren wurde mit Vollzugriff gesetzt.

Sobald ich mit einem Mitglied der Domänen-Administratoren über die Hyper-V bzw. Failover-Cluster Konsole etwas auf den Share ablege oder ändere, trägt sich wie unten im Screenshot automatisch der Computeraccount  und der CREATOR OWNER ein.

 

NTFS Permission Tab Hyper-V

 

 

Weil OWNER auf die lokalen Administratoren zeigt, muss dieser noch auf die Domänen-Administratoren geändert werden.

effective access Tab Hyper-V Die lokalen Administratoren sind jetzt keine Owner mehr, und haben somit keinen effektiven Zugriff mehr auf die Daten.

 

Die Berechtigungen können nicht zu restriktiv sein. Sollte einmal ein Recht fehlen, z.B. wenn ein neuer Hyper-V Host hinzukommt, wird dieser automatisch mit eingetragen. Die oben genannte Fehlermeldung hat damit einen anderen Ursprung.

 

 

Constrainted Delegation

Das Problem ist nicht die Berechtigung sondern ein fehlendes bzw. ein falsch ausgestelltes Kerberos Ticket.

Die Ursache ist, das mein Server 2012R2-Cl1 seinen Membernode 2012R2-Cl2 über den Failover-Cluster Manager konfigurieren möchte, aber nicht in dessen Auftrag beim SOFS aggieren darf. Soll heissen, geht man mit RDP auf den Node 2012R2-Cl2 und konfiguriert diesen lokal, tritt der Fehler nicht auf.

Auf Dauer ist das kein Zustand immer lokal den zu konfigurierenden Server aufzusuchen. Stuft man irgendwann den Server zum Core herunter oder setzt den Hyper-V Server ein, gibt es auch diese Notlösung nicht mehr.

Zur Lösung dieses Verhaltens gibt es die Delegation, seit einiger Zeit auch die eingeschränkte Delegation.

 

 

Active Directory Users and Computer, Account des Computers der eine Delegierung erhalten soll

Active Directory Users and Computers Delegation Tab Do not Trust this Computer for Delegation

 

 

Das Ziel der Delegierung auswählen, in meinem Fall das virtuelle Computerobjekt des SOFS Clusters, bei einem normalen SMB3 Share wäre das das Computerobjekt des Servers. Service Type für SMB ist CIFS

Active Directory Users and Computers Delegation Tab Trust this Computer for Delegation

 

 

Das Speichern funktioniert jetzt auf Anhieb, Fehler sollte nicht mehr auftreten

Hyper-V vm settings virtual hard disk

 

 

 

Holger Wache

Holger Wache