Jump to content

Neuerungen für Active Directory unter "Server vNext" (und weitere vNext Neuigkeiten)


Empfohlene Beiträge

vor 21 Stunden schrieb MurdocX:

Spannend finde ich das Thema der Kommunikation untereinander. Ist Kommunikation untereinander ist dann NTLM oder Kerberos?

Soweit ich es aus der Präsentation verstanden habe, weder noch. Es wird beim Aufbau des Clusters ein Secret ausgetauscht, und das dient als Basis für die Authentifizierung der Kommunikation der Knoten untereinander, so ähnlich wie die zertifikatsbasierte Authentifizierung in Hyper-V für Replikation und Live Migraiton.

bearbeitet von cj_berlin
Link zu diesem Kommentar
Am 12.2.2024 um 08:43 schrieb cj_berlin:

Soweit ich es aus der Präsentation verstanden habe, weder noch. Es wird beim Aufbau des Clusters ein Secret ausgetauscht, und das dient als Basis für die Authentifizierung der Kommunikation der Knoten untereinander, so ähnlich wie die zertifikatsbasierte Authentifizierung in Hyper-V für Replikation und Live Migraiton.

 

Danke euch, auch an @MurdocX.

Wenn ihr ein update dazu habt ist das sehr spannend da ich einen entsprechenden use case vorliegen habe in den nächsten Monaten.

Link zu diesem Kommentar
Am 15.2.2024 um 21:16 schrieb testperson:

Wo brauchst du das Update? Ob das Kerberos, NTML oder was ganz anderes ist? Oder einfach nur, ob es jetzt auch ein Hyper-V Failover Cluster domainless inkl. Live Migration lauffähig ist?

Genau, ob das Kerberos oder NTLM oder zertifikatsbasierte Authentifizierung ist.
Oder etwas schwarzmagisches.

Link zu diesem Kommentar

Wenn ich Kerberos komplett blocke, lässt sich der Cluster Manager nur öffnen, wenn die Cluster Ressource auf dem eigenen Node liegt. Öffnet man den Cluster Manager auf Node1, schiebt die Cluster Ressource auf Node2 und öffnet dort den Manager, lässt sich problemlos von beiden Knoten das Cluster bedienen. Was gar nicht funktioniert - egal ob Kerberos only oder mit NTLM, ist die VM Konsole einer VM auf dem anderen Knoten zu öffnen. (Das wird aber vermutlich daran liegen, dass ich das noch nicht umgesetzt habe (Remotely manage Hyper-V hosts | Microsoft Learn)).

 

"Incoming NTLM" auf "Deny all domain accounts" oder "Allow all" und folgende Ausnahmen scheinen laut Eventlog das Minimum zu sein ;-)

Auf Knoten ADLESS-HV01:

RPCSS/ADLESS-HV02
RPCSS/ADLESS-HV02.workgroup.cluster
host/ADLESS-HV02
host/ADLESS-HV02.workgroup.cluster
MSServerClusterMgmtAPI/adless-cluster02
MSServerClusterMgmtAPI/adless-cluster02.workgroup.cluster
cifs/ADLESS-HV02
cifs/ADLESS-HV02.workgroup.cluster

Auf Knoten ADLESS-HV02:

RPCSS/ADLESS-HV01
RPCSS/ADLESS-HV01.workgroup.cluster
host/ADLESS-HV01
host/ADLESS-HV01.workgroup.cluster
MSServerClusterMgmtAPI/adless-cluster01
MSServerClusterMgmtAPI/adless-cluster01.workgroup.cluster
cifs/ADLESS-HV01
cifs/ADLESS-HV01.workgroup.cluster

 

Link zu diesem Kommentar

In der aktuellen Preview für Server (oder auch Win 11) bin ich gerade über Änderungen im "native LAPS" gestolpert: Announcing Windows 11 Insider Preview Build 26040 (Canary Channel) | Windows Insider Blog

  • Erstellung eines verwalteten, lokalen Accounts inkl. "Zufallsgenerator" für ein Prefix des Accounts, welcher beim Passwortwechsel ebenfalls rotiert
  • Die Passwortkomplexität kann jetzt leicht zu verwechselnde Zeichen auslassen; Kennwortsätze können automatisch generiert werden
  • Ein "Image Rollback Detection Feature" wurde implementiert
Am 17.2.2024 um 20:52 schrieb Apex:

Genau, ob das Kerberos oder NTLM oder zertifikatsbasierte Authentifizierung ist.

 

Im Personal Store der lokalen Hyper-V Hosts liegt ein Zertifikat "CLIUSR":

  • Zertifikat gelöscht -> Keine Livemigration mit Authentifizierungsfehler
  • Zertifikat wieder importiert -> Livemigration

Im Hyper-V Manager, lässt sich die Livemigration allerdings nicht auf Kerberos konfigurieren. Die GUI vermeldet, dafür sei ein Domain-join nötig. Die PowerShell sagt:

Get-VMHost | fl *auth*
VirtualMachineMigrationAuthenticationType : 4

Ich hätte da "Kerberos" oder "CredSSP" erwartet, kann aber auch mit "4" leben. :)

Link zu diesem Kommentar
Am 17.2.2024 um 20:48 schrieb testperson:

Konntest du den Cluster Kerberos-only erstellen? Bei mir war eine Validierung mit aktiviertem NTLM blocking nicht möglich. Jetzt "im Betrieb" ist Kerberos-only kein Problem.

 

Die VMs liefen beide einfach mal so eine Weile weiter. Nun ist der Cluster nicht mehr existent. Fehler: Failed to register cluster name in the local user groups: incorrect function.

Cluster entfernt, Cluster neu erstellt. Nun kann ich ihn ohne NTLM auch nicht wieder erstellen. Warum es erst bei mir anfangs ging, keine Ahnung. (vll kein gpupdate durchgeführt).

 

Läuft er bei Dir noch?

Link zu diesem Kommentar
vor 11 Stunden schrieb MurdocX:

Läuft er bei Dir noch?

 

Ja, mit den o.g. Ausnahmen läuft er. ;) "Kerberos only" konnte der Cluster nach einem Shutdown nur per Powershell gestartet werden. Die Failover Cluster MMC scheint noch etwas an NTLM zu hängen, würde mich aber auch nicht wundern. Auf meiner Agenda steht derzeit noch ein Test, wie sich alles mit dem Windows Admin Center verhält.

 

Beide Clusterknoten haben auch problemlos das In-Place Upgrade über Windows Update mitgemacht.

 

BTW.: Auf frisch installierten Systemen mit der Build 26063 ist Copilot überall "aktiv".

Link zu diesem Kommentar

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...