Synology Directory Server | Passwort beim Zugriff auf ein Netzlaufwerk

image

An dieser Stelle möchte ich auf den vielleicht wichtigsten Artikel im Synology Knowledge Center hinweisen Smile

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Es geht hier um eine nicht korrekte Auswertung von Gruppenmitgliedschaften beim Zugriff auf ein Netzlaufwerk.

Technischer Hintergrund

Einem Benutzer in der Domain wird über ein Anmeldeskript (login.cmd) ein neues Netzlaufwerk verbunden. Die Vergabe der Berechtigungen dazu erfolgt relativ einfach indem der Benutzer Mitglied in einer dafür erstellen Gruppe in der Domain wird. Diese Gruppe hat wiederum entsprechende Berechtigungen auf dem Netzlaufwerk.

  • Sepp (Benutzer) – Mitglied in der Gruppe “_ SN Immobilien Users”
  • Die Gruppe “_ SN Immobilien Users” hat R/W-Zugriff auf den Share \\sn-nas-15\immo

Das Problem

Für das neue Netzlaufwerk, muss auf einmal im Fenster des Anmeldeskript ein Passwort angegeben werden, das funktionale Passwort von Sepp wird hier aber nicht akzeptiert. Es bleibt nur die Möglichkeit das Fenster zu schließen und damit die darauffolgenden Maßnahmen (weitere Laufwerke usw.) abzubrechen.

Das erwartete Verhalten wäre, dass Sepp durch seine Mitgliedschaft in der Gruppe “_ SN Immobilien Users” die entsprechenden Berechtigungen auf dem Netzlaufwerk besitzt. Durch seine neue Anmeldung, wird der Security-Token neu erstellt und die (neue) Gruppen-Mitgliedschaft fließt in diesen mit ein.

Die Lösung

Auf dem Synology NAS müssen die folgenden beiden Änderungen durchgeführt werden.image

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Der Windows Client muss wie folgt behandelt werden, wobei bei mir ein Neustart genügte.

image

Danach war das Netzlaufwerk über die passende Gruppenmitgliedschaft im Zugriff.

Update: Ein defektes Computerkonto, kann ebenfalls den Zugriff auf ein Laufwerk verhindern. Die Symptome sind dabei die gleichen, es wird ebenfalls nach einem Benutzer und Passwort gefragt und dieses nicht akzeptiert. Es genügt dann den PC aus der Domäne heraus- und wieder reinzunehmen.

Enjoy it, b!

Synology Directory Server | Hyper-V Replica schlägt fehl–Kerberos Fehler

Ich arbeite bei kleinen Projekten gerne mit dem Synology Directory Server als Ersatz für das Microsoft Active Directory (AD). Bei ein paar Benutzern, lassen sich hier doch einige Kosten sparen. Nun kommt aber auch dort gelegentlich 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, hat auch bis zur Aktivierung der Hyper-V Replication problemlos funktioniert.

  • Join der beiden Hyper-V Hosts in die Domain des Synology Directory Servers
  • Öffnen der Firewall auf den Hyper-V Hosts um über Port 80 der 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 dieser Fehlermeldung konfrontiert und konnte auf Anhieb nichts damit anfangen.

image

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

Die Namensauflösung funktionierte und auch die ServicePrincipalNames sind registriert.

image

Auch die Ports 80 und 443 sind über die Firewall geöffnet und antworten wie erwartet.

Mein Verdacht fiel nach einiger Zeit auf dem Synology Directory Server, dieser stellt quasi eine Domain mit dem folgendem Functional-Level bereit.

  • Domain functional level: Equal to Windows Server 2008 R2

Die Hyper-V Replica wurde mit Windows Server 2012 vorgestellt, was aber nicht zwingend heißen muss, dass die Domain ebenfalls auf diesem Level sein muss. Ich denke aber das darin und vielleicht in Verbindung mit der Tatsache, dass hier eigentlich Samba 4.10 läuft, hier das Problem liegen könnte.

Als Alternative wollte ich die Authentifizierung per Zertifikat verwenden.

image

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.

image

Danach wird das Root-Zertifikat erstellt. Dazu habe ich die folgenden Punkte geändert (Zeile 26).

  • KeyUsage CertSign  in
  • KeyUsage CertSign, CRLSign, DigitalSignature

Darüber hinaus in Zeile 27

  • KeyLength 2056 in
  • KeyLength 4096

image

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

image

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

image

Auch bei der Erstellung der Server-Zertifikaten habe ich ein paar Änderungen vorgenommen.

Hinzufügen eines weiteren Parameters (Zeile 64), wobei ich dazu (Zeile 60) den FQDN erstelle

  • DnsName $fqdn, $name
  • KeyLength 4096

image

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

image

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

image

Kleiner Tipp, der “\” am Ende des Pfads erstellt das Verzeichnis automatisch.

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

image

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

image

image

So, damit sollte die Hyper-V Replikation eigentlich funktionieren, was aber nicht der Fall war. 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.

image

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

Enjoy it, b!