Ich arbeite bei kleinen Projekten gerne mit dem Synology Directory Server als Ersatz für das Microsoft Active Directory (AD). Bei wenigen Benutzern lassen sich damit einige Kosten sparen. Gelegentlich besteht jedoch auch hier die Anforderung, eine virtuelle Maschine (VM) hochverfügbar bereitzustellen. Dafür habe ich bisher immer den Microsoft Hyper-V Server (2019) in Verbindung mit der Hyper-V Replica verwendet.

Das klassische Setup funktionierte bis zur Aktivierung der Hyper-V-Replikation problemlos:

• Join der beiden Hyper-V-Hosts in die Domäne des Synology Directory Servers
• Öffnen der Firewall auf den Hyper-V-Hosts, um über Port 80 oder 443 zu replizieren
• Verwendung der Kerberos-Authentifizierung (HTTP) für die Replikation
• Einrichten der Hyper-V Replica für eine oder zwei VMs

Allerdings wurde ich am Ende der Konfiguration mit folgender Fehlermeldung konfrontiert – und konnte zunächst nichts damit anfangen:

Ja klar, es gibt ein Problem mit Kerberos … aber warum?

Die Namensauflösung funktionierte, und auch die ServicePrincipalNames waren registriert.

Auch die Ports 80 und 443 waren über die Firewall geöffnet und antworteten wie erwartet.

Mein Verdacht fiel nach einiger Zeit auf den Synology Directory Server. Dieser stellt eine Domäne mit folgendem Functional Level bereit:

• Domain Functional Level: Equal to Windows Server 2008 R2

Die Hyper-V Replica wurde mit Windows Server 2012 eingeführt – was aber nicht zwingend bedeutet, dass die Domäne ebenfalls auf diesem Level sein muss. Ich vermute jedoch, dass hier – möglicherweise in Verbindung mit der Tatsache, dass intern Samba 4.10 läuft – das Problem liegt.

Als Alternative wollte ich nun die Authentifizierung per Zertifikat verwenden.

Dabei bin ich über eine Reihe von Herausforderungen gestolpert, die sich aber letztendlich lösen ließen. Als Grundlage habe ich diese Anleitung verwendet, die aber nur mit kleineren Modifikationen funktionierte.

Ein wichtiger Unterschied ist auf jeden Fall, dass meine beiden Hyper-V Hosts in der Domain verbleiben sollen, also nicht in einer Workgroup betrieben werden.

• Insgesamt werden n+1 (N = Anzahl der Hyper-V Hosts die an der Replikation teilnehmen) Zertifikate erstellt. Für jeden Hyper-V Host eines (das Server-Zertifikat) und das Root-Zertifikat. Bei zwei Hosts, haben wir damit drei Zertifikate
• Während das Root-Zertifikat auf jedem der Hyper-V Hosts installiert wird, bekommt jeder Host ein eigenes Server-Zertifikat

Auf dem ersten Knoten wird eine PowerShell-Sitzung als Administrator gestartet und dazu die folgenden Variabel angelegt.

–

Dabei bin ich auf einige Herausforderungen gestoßen, die ich aber lösen konnte. Als Grundlage diente mir eine Anleitung, die jedoch nur mit kleineren Anpassungen funktionierte.

Ein wichtiger Unterschied: Meine beiden Hyper-V-Hosts sollen in der Domäne verbleiben und nicht in einer Workgroup betrieben werden.

• Insgesamt werden n+1 Zertifikate benötigt (n = Anzahl der Hyper-V-Hosts, die an der Replikation teilnehmen). Für jeden Host ein Server-Zertifikat sowie ein Root-Zertifikat. Bei zwei Hosts ergibt das drei Zertifikate.
• Das Root-Zertifikat wird auf jedem Hyper-V-Host installiert, jeder Host erhält zusätzlich ein eigenes Server-Zertifikat.

Auf dem ersten Host wird eine PowerShell-Sitzung als Administrator gestartet und die folgenden Variablen gesetzt:

Dann wird das Root-Zertifikat erstellt. Dafür habe ich die folgenden Änderungen vorgenommen (Zeile 26).

• KeyUsage CertSign  in KeyUsage CertSign, CRLSign, DigitalSignature

In Zeile 27

• KeyLength 2056 in KeyLength 4096

Der Server, auf dem das Root-Zertifikat wurde, muss diesem ebenfalls vertrauen. Darum wird das Zertifikat von Personal nach Trusted Root Certification Authorities kopiert.

Nun werden auf demselben Knoten sowohl das Root-Zertifikat exportiert als auch die Server-Zertifikate erstellt.

Auch bei der Erstellung der Server-Zertifikaten habe ich Änderungen vorgenommen:

• Hinzufügen eines weiteren Parameters (Zeile 64), wobei zuvor (Zeile 60) der FQDN erstellt wird:
  DnsName $fqdn, $name
• KeyLength 4096

Auf allen Hyper-V Hosts muss nun die Prüfung der Zertifikate deaktiviert werden.

Nun werden die Zertifikate auf die anderen Knoten (hier nur einer) verteilt.

Tipp: Der “\” am Ende des Pfads erstellt das Verzeichnis automatisch.

Nun wird auf dem zweiten Knoten sowohl das Root- als auch der Server-Zertifikat importiert

Das sieht dann auf jedem Hyper-V Host wie folgt aus.

Damit sollte die Hyper-V Replikation eigentlich funktionieren – tat sie aber nicht. Zusätzlich zur certificate-based Authentification (HTTPS), musste ich auch noch die Verwendung von Kerberos (HTTP) aktivieren! Warum, kann ich nicht genau sagen und muss hier nochmals mit einem Netzwerk-Trace, der Sache auf den Grund gehen.

Mit dieser Konfiguration funktioniert nun die Hyper-V Replikation auch mit Hyper-V Hosts, die Mitglied in einer Samba-Domain und dem Synology Directory Server sind.

Enjoy it, b!