Synology Directory Server | Zertifikat abgelaufen

Wenn im Synology DSM das Zertifikat für den Synology Directory Server (SDS) abgelaufen ist, gibt es die Möglichkeit dieses Online wieder zu verlängern. Dazu sind die folgenden Schritte notwendig:

  1. Der Vorgang muss auf jedem Synology Directory Server (also auf jedem NAS) explizit durchgeführt werden (in diesem Netzwerk sind zwei davon vorhanden)
  2. Der DNS muss “korrekt” konfiguriert sein, was einfach bedeutet das mit dem NAS eine Verbindung in das Internet möglich ist und externe Domains aufgelöst werden
  3. Das DSM muss von außen über Port 80 (HTTP) erreichbar sein. Dazu muss auf dem Router eine Weiterleitung von Port 80 extern auf die <NAS-IP>:80 intern eingestellt werden. Danach ist diese Regel sofort wieder zu deaktivieren!

Im Detail sieht das wie folgt aus:

image

  • Issued by: domain.tld | Beispiel home.local
  • Subject Alternative Name: domain-controller.domain.tld | Beispiel mausi.home.local

Hier die Regel im Router, in diesem Fall ein Mikrotik:

image

Das hätte man auch ein wenig anders realisieren können, aber für die zwei Minuten funktioniert es sehr gut.

Nun wird im DSM unter Security / Certificate das Zertifikat ausgewählt und mit Action / Renew certificate das Renewal angestoßen.

image

Zur Sicherheit gibt das DSM nochmals einen Hinweis auf die notwendige DNS / Firewall-Konfiguration.

image

Mit  Renew Certificate dauert der Vorgang nur wenige Sekunden und es ist lediglich erforderlich, die Seite erneut zu laden.

image

Jetzt wieder Port 80 auf dem Router schließen und wir sind fertig.

Enjoy it, b!

Default Domain Policy | Fehlende Remote Installation Services in der GPO

Eigentlich habe ich die Default Domain Policy in den Active Directory Domains (AD) meiner Kunden nie verändert. Jetzt, da ich durch den Verlust meines geliebten Small Business Servers vermehrt den Synology Directory Server einsetze (sagen wir einfach mal Samba dazu) bin ich beim Aufräumen auf eine veränderte Default Domain Policy gestoßen. Deren Einstellung wurden im Zuge einer Migration auf den Windows Small Business Server erweitert (Remote Installation in der User Configuration).

image

Von den Zeitstempeln (Created und Modified) würde das passen.

image

Ein Löschen der Einträge war leider nicht möglich, da diese nicht im Editor (gpedit) angezeigt wurden. Schließlich konnte ich aber die dazugehörige Richtlinien-Datei mit der GUID {31B2F340-016D-11D2-945F-00C04FB984F9} im SysVol finden und die Default Domain Policy bereinigen.

image

Man kann auch mit einem dir nachschauen, ob die Einstellungen dort wirklich zu finden sind (just to be sure).

image

Gelöscht wird über eine mit administrativen Rechten ausgeführte cmd.exe oder PowerShell und zwar der USER\Microsoft\Remote Installation Ordner und nicht die Policy selbst!

:: Löschen des Ordners "Remote Install" in der Policy
rd "\\synology-nas\sysvol\mydomain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\USER\Microsoft\Remote Install" /s /q

Nochmals und aus gegebenem Anlass, nicht die Policy löschen da es sich auch noch um die Default Domain Policy handelt und dcgpofix nur auf einem Windows Domain Controller ausgeführt werden kann, der ja in diesem Fall nicht vorhanden ist.

Enjoy it, b!

LSA 40970 | Fehlende SPNs im Synology Directory

Hier geht es nicht nur um den Synology Directory Server, sondern auch um ein Problem in einer Samba-Domain allgemein. Letztendlich basiert der Synology Directory Server auf Samba und damit kann für eine Fehleranalyse und Behebung auf die Informationen im Samba-Wiki zurück gegriffen werden und natürlich auch (mit einer gewissen Vorsicht) die RSAT-Active Directory Tools vom Microsoft zum Einsatz kommen.

Hier noch ein Hinweis in eigener Sache:
Es handelt sich hier um eine Test/Labor-Umgebung, allerdings aus einem Kundenumfeld, darum habe ich die Namen entsprechend ersetzt.

Nach einer Reihe von Reparaturen in der Labor-Domain dslab.local, zeigte ein Computer die folgende Warnung im Ereignissprotokoll.

image

Da die Domain zwei DCs hat, war es kein großes Ding die SPNs beider Systeme miteinander zu vergleichen und tatsächlich fehlten dem nc-nas-11 eine Vielzahl von SPNs, die auf dem nc-ncs-14 zu finden waren.

image

Gegenüber den Einträgen des nc-nas-14 ist das recht spärlich Smile

image

Nachdem die fehlenden SPNs, analog zu den Einträgen des nc-nas-14 mit setspn registriert waren, verschwand auch der LSA 40970 im Ereignisprotokoll.

Enjoy it, b!

Synology SMB | Probleme mit Windows Juli-Updates (07/2023) | SecureChannel

Mit den Juli-Updates für Windows (10, 11 und Windows Server 2012R2 bis 2022), gibt es Probleme mit der Authentifizierung an einem Synology-NAS. Die sich wie im Folgenden beschrieben, äußern können.

Fehlerbilder (zumindest jene, die mir untergekommen sind)

  1. Windows meldet einen 3210, Netlogon Fehler mit dem Hinweis das die Authentifizierung mit dem “Windows Domain Controller” fehl geschlagen ist. In diesem Falle ist der “Windows Domain Controller” ein Synology NAS mit dem dem Synology Directory Server (Samba)


    image

  2. Die Anmeldung an einem Windows-System über Remote Desktop und konfigurierter NLA, funktioniert nur noch im lokalem Netz aber nicht mehr über das Internet

    image

  3. PowerShell meldet einen Fehler beim Test des SecureChannels zwischen dem Windows System und dem Synology NAS (das durch den Synology Directory Server als Domain Controller arbeitet

    Test-ComputerSecureChannel (Rückgabe = False), korrekt wäre hier True

    image

    Die Option –Repair funktioniert übrigens auch nicht

    image

  4. Der Zugriff auf Freigaben der Synology-NAS über den FQDN schlägt fehl oder ist nicht stabil

Ein Workaround aber keine Lösung, stellt die Deinstallation des Updates dar.

:: Deinstallation Juli-Update Windows 10 21H2/22H2
wusa /uninstall /kb:5028168

(für andere Windows Betriebssysteme, oben die entsprechende KB-Nummer einsetzen)

Hintergrund

Zum einen verwenden Synology und andere NAS-Hersteller Samba für die Implementierung des Dateidienstes (Fileservices) auf ihren NAS-Geräten. Da wird in der Regel nur angepasst, aber die Basis ist immer Samba. Dort ist das Problem in Form eines Bugs (15418) schon bekannt.

Genau genommen ist das aber kein Bug bzw. Fehler im eigentlichen Sinne, sondern eine noch nicht erfolgte Anpassung an die Strategie von Microsoft die Verwendung des Kerberos-Protokolls in Windows abzusichern. Dieses Ansinnen tut Microsoft aber nicht in dem entsprechenden KB-Artikeln zum Juli-Update kund, sondern erläutert die Roadmap explizit in KB5020805: How to manage Kerberos changes related to CVE-2022-37969

Samba als sagen wir mal Server-Komponente auf den NAS-Systemen, muss das neue verhalten der Windows-Systeme und des Kerberos interpretieren können. Was zumindest bis heute, noch keine offizielle Implementierung im SMB-Packet von Synology zur Folge hatte.

Die Lösung

Im Rahmen eines Support-Calls bei Synology war aber das Problem schon bekannt und man konnte mir mit einem “Private-Fix” des SMB-Services (SMB-Packets) weiterhelfen. Dieses Paket ist inzwischen auch zum Download über die englisch-sprachige Synology-Community erhältlich.

https://community.synology.com/enu/forum/1/post/161649

Ich bitte darum den Artikel dort ausführlich zu lesen und ggf. doch einen Support-Call bei Synology zu öffnen. Einfach aus dem Grund, da es für unterschiedliche DSM-Versionen und Prozessor-Architekturen der NAS-Systeme verschiedene Antworten gibt.

Bei mir hat das bereitgestellte und manuell installierte Paket die Probleme gelöst. Eine positive Rückmeldung an den Support von Synology ist ebenfalls erfolgt und darum hoffe ich, dass ein offizielles Update nicht zulange auf sich warten lässt.

Enjoy it, b!

racknex UM-INT-001 | SBE Compute Unit

Langsam muss ich mir doch Gedanken über die Umbenennung dieses Blogs machen, eine Anregung war SBE = Small Business Environments, was mir persönlich sehr gut gefällt. Der SBS (Small Business Server) verliert mit jeder Migration bei meinen Kunden, für mich an Bedeutung und auch aus Sicht des Supports von Microsoft sind seine Jahre gezählt.

Zeit über neue Ansätze nachzudenken und wieder einen Artikel über meine Freunde in Österreich zu schreiben, hiermit beste Grüße an racknex und die erfolgreiche Verwendung der UM-INT-001 als Rackmount für meine SBE Compute Unit.

UM-INT-001

Credits und Copyright liegen bei racknex

“Für was brauchen wir den eigentlich noch die beiden Server?” Fragte mich ein Kunde, nachdem wir seine Datei- und Anmeldedienste (und alles andere, was ein Small Business Server Essentials 2012 R2 so macht) auf zwei Synology NAS Systeme migriert hatten. Sein Szenario sah zu diesem Punkt wie folgt aus:

  • VPN-Server
  • Anmeldedienste (Synology Directory Server) und DNS
  • Dateidienste (SMB/CIFS)
  • DHCP
  • Backup der Arbeitsplätze und virtuellen Maschinen (VMs)
  • Surveillance (für die Videokameras in der Werkstatt) sowie Cloud-Backup
  • Docker Container mit WSUS Offline Update

Das alles verbunden mit einem zweiten Synology NAS welches zusätzlich den Anmeldedienst aktiv absichert und ansonsten für die Replikation von Snapshots und die Sicherung des primären NAS zum Einsatz kommt.

Gut, natürlich wir haben ja immer noch die Server, die inzwischen nicht mehr viel zu tun haben. Dort laufen gerade mal drei VMs (virtuelle Maschinen), eine für das Management der Drucker, die zweite für das ziemlich schrottig programmierte Warenwirtschaftssystem sowie eine dritte mit einem virtuellen Desktop und Windows 11. Die Absicherung der VMs erfolgt zum einen durch das Active Backup von Synology und natürlich über eine Hyper-V Replikation. Aufgefallen sind die beiden Server vor allem, da sie einen besonders hohen Geräuschpegel verursachten, der besonders im Sommer ziemlich auf die Nerven ging.

Darum musste auch hier eine Alternative her und war durch einen Zufall schnell gefunden. Während der Suche nach Treibern auf der Intel Homepage bin ich auf einen Artikel gestoßen, dass Intel NUC Systeme (zumindest einige von ihnen) 24×7 betrieben werden können. Bei fast allen meiner Kunden laufen die PCs ohnehin 24×7 und das nicht nur 3 oder 4 Jahre, insofern hatte ich keine Probleme mit der Vorstellung das sowas auch mit einem Intel NUC möglich wäre und sogar, im Falle von Intel, unterstützt wird. Eine Analyse der auf den Servern vorgehaltenen Kapazitäten ergab, dass zwei Intel NUCs mit dem i5 der 11ten Generation sowie 32GB Hauptspeicher und einer 2TB NVMe ausreichen würden. Das Ganze hat Brutto keine 2.000 € gekostet und konnte mit dem Rackmount von racknex sauber in das Rack eingebaut werden.

UM-INT-001

Nach der Migration der VMs hatten wir (der Kunde und ich) zwei Aha-Erlebnisse.

  • Zum einen reduzierte sich die Temperatur im Serverraum um 5° und die Kühlung musste im Sommer nicht mehr aktiv sein
  • Der Intel NUC mit der NVMe war so schnell, dass die VMs bei einem Neustart des Intel NUCs sogar eine reconnect einer RDP-Session ermöglichten

Die Ausfallsicherheit wird nach wie vor durch die Hyper-V Replica und dem Microsoft Hyper-V Server 2019 sichergestellt und auch hier sichert Synology Active Backup die VMs.

Das Setup läuft nun seit 3 Monaten ohne Probleme, mit Crystaldiskinfo prüfe ich die NVMe Laufwerke und lasse mir einen Alert schicken, wenn sich gravierende Parameter ändern.

Damit stellen sich zum Schluss zwei Fragen.

  1. Wieso hast Du nicht den Synology Virtual Machine Manager und die beiden NAS Systeme verwendet?
  2. Brauchst Du jetzt keine “echten” Server mehr?

Zu 1. muss ich sagen, dass in diesem Fall zwei der drei VMs schon eine ordentliche Rechenleistung benötigen. Nichts mit High-End, aber mehr als üblicher Weise ein Atom oder Celeron-Prozessor von Intel liefern. Ein Setup analog zu den Intel NUCs auf den beiden Synology NAS Systemen hätte deren Kosten und vor allem auch deren Geräuschpegel deutlich nach oben geschraubt. Dazu stellen die Intel NUC Systeme eine einfach Exit-Strategie dar, sollte die Idee aus irgendeinem Grund nicht funktionieren, dann machen wir normale Arbeitsplätze draus und kaufen wieder “echte” Server.

Zu 2. Für genau diese Anforderung des Kunden reichen die Intel NUCs mit Hyper-V Replica definitiv aus, zumal wir ja auch eine ordentliche Datensicherung haben. Richtige und damit vor allem teure und laute Server werde ich nach wie vor verwenden, wenn die Option mit den Synology NAS Systemen und nur zwei bis drei kleineren VMs nicht besteht. Dann machen wir alles wie gehabt, erprobt und solide aber auch deutlich teurer und wärmer. Da wir aber im kommenden Winter nicht wissen, wie kalt es bei uns werden wird, kann der Kunde ja die alten Server als Heizung mitlaufen lassen Smile

Bis bald mal wieder und enjoy it, b!

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!