MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

SMB Service Migration

Bei der Restrukturierung von Firmen, M&A aber auch Server und AD-Forest Umgebauten, gibt es neben Cloud, Exchange, Client etc. auch immer noch Dateiserver. Sie haben richtig gelesen. Clients und Programme nutzen auch in Zeiten der Cloud natürlich noch lokale Dateiserver, d.h. Zugriff über SMB auf Windows oder Samba-Server oder spezielle NAS-Systeme, z.B. von NetApp oder Synology.

Die ideale Welt

Die Zusammenarbeit von Menschen über zentrale Server ist keine neue Technik sondern war zu meiner Ausbildung (1988-1991) der Auslöser für den Aufbau lokaler Netzwerke mit ArcNet, 10Base2, Token-Ring etc. Servern mit Novell NetWare, NFS, Banyan Vines, OS/2 oder auch LanManager Server. Genauso lange kennen wir Zugriff auf "\\servername\freigabe" oder beim Einsatz von DFS mit "\\domainname\share". Diese Funktion ist auch heute (2026) noch immer aktuell und wird nach meiner Einschätzung auch noch viele Jahre weiter genutzt, selbst wenn es für Office-Dokumente mit SharePoint/OneDrive und Sourcecode mit Git besser geteilt werden können. Schon viele Jahre habe ich auf Datenhaltung auf Dateiservern beschrieben, wie ich Freigaben für Benutzer organisieren würde.

  • DFS oder Alias statt Servername
    Jeder Server hat einen kurzen Namen aber auch einen FQDN. Beide sind für Zugriffe von Clients nicht ratsam, da sich diese Namen auch ändern können, z.B. wenn sie den Server durch neue Server tauschen, Server zusammenführen oder aufteilen etc. Viel besser finde ich den Einsatz von "ungebundenen" Namen. Wenn Sie im Internet auf eine Adresse wie "www.<firmendomain>" gehen, dann erwarten Sie doch auch nicht, dass der oder die Computer dahinter "www" heißen.
    Bleibt nur noch die Frage, ob sie nun für jeden Service oder Share gleich einen neuen Namen vorsehen oder ein Domain-DFS einsetzen und die Freigaben dann unter dem Domainnamen erreichbar machen, z.B. neben \\<domain>\SYSVOL und \\<domain>\NEGTLOGON kann es ja auch \\<domain>\HOME und \\<domain>\Projektename geben. Wobei diese Pfade bei einem Umzug in einen anderen Forest natürlich doch wieder nicht passen. In einigen Fällen können Sie sogar die Daten per DFSR, also DFS-Replikation auf neue Server übertragen.
  • Rechte auf Share für "Jeder" oder zumindest "Authenticated Users"
    Ich verlasse mich nie auf die Rechte eines Shares, sondern immer nur auf die echten Berechtigungen auf dem Dateisystem. Wenn Sie nämlich z.B. einen Share nur für eine Gruppe freigeben und auf NTFS dann "jeder" lassen, dann ist der Schutz auf den ersten Blick gegeben. Aber Suchmaschinen, KI-Systeme oder auch nur andere Zugriffe per FTP, IIS o.ä. an SMB vorbei, werden nicht beschränkt. Es wäre nicht das erste mal, dass ein Benutzer in einer "Intranet-Suche" auch Informationen als Vorschau sieht, die er selbst direkt nicht erreichen kann.
  • NTFS Rechte aufaddieren, nie Vererbung unterbrechen
    Ein Share ist nur der Einstiegspunkt. Die effektiven Berechtigungen basieren auf dem Dateisystem und eine Verzeichnisstruktur dient nicht nur der Aufteilung der verschiedenen Dateien nach Fachbereichen und Themen sondern auch zur Berechtigung. Wenn die Berechtigungen auf einem Unterverzeichnis eingeschränkt sein sollen, dann ist es besser, darüber die Rechte gar nicht erst für "Diesen und Unterordner" zu vergeben sondern nur auf "Diesen Ordner". Dann müssen Sie auf dem Unterordner auch keine Vererbung unterbrechen sondern addieren einfach die gewünschten Berechtigungen.
  • Usage und Zuständigkeit
    Diese zusätzlichen Einstellungen und Festlegungen werden gerne übersehen. Schon bei der Einrichtung müssen sie die Hausordnung festlegen, z.B. welche Dateien auf den Bereichen erwartet werden-. Sie könnten z.B. die Maximalgröße von Dateien festlegen und gewisse Dateien (COM, EXE, BAT) verbieten. Dazu gehörten auch Ansprechpartner für Datenschutz, Kostenstelle und Management. Zumindest sollten Sie einen Besitzer ("Owner") festlegen, der bei Rückfragen aber auch bei Verstößen verantwortlich ist.
  • Quota und Verfügbarkeit
    In Absprache mit der zuständigen Person sind SLAs hinsichtlich Verfügbarkeit, Datensicherung und Versionierung festzulegen. Auch die Zugriffsintensität (Übertragungsvolumen) und die erlaubten Clients sollten bekannt sein. nicht dass eine Freigabe ungeplant mit Terabytes an Videos gefüllt wird, die dort auch geschnitten werden.
  • Dokumentation
    Perfekt wird so ein Dateibereich dann, wenn Sie die vergebenen Berechtigungen, SLA, Nutzer, Zugriffe etc. auch dokumentieren.

Das wäre dann schon nahe an einer idealen Welt, die bei einer Migration problemlos und vorhersehbar übertragen werden kann.

Herausforderungen

Wir wissen aber alle, dass "gewachsene" Dateiserver und Strukturen unterschiedlichsten Konzepten folgen. Administratoren können ihre Systeme nur so gut einrichten, wie Sie selbst ein Konzept und die dazu notwendigen Kenntnisse haben. Das war aber nicht nur in der Anfangszeit der Dateiserver noch nicht vorhanden sondern auch heute finde ich immer wieder Umgebungen, wo immer noch die falschen Konfigurationen weiter gepflegt werden. Hier ein paar Beispiele:

  • Unterbrochene Vererbung
    Wer auf einer übergeordneten Ebene zu viele Berechtigungen vergeben hat und diese in einem Unterverzeichnis abweichend konfigurieren möchte, kommt gerne mal auf den Gedanken die Vererbung einfach zu unterbrechen. Das funktioniert auf den ersten Blick wunderbar aber hat einige Nachteile, da nur noch die explizit ab der Stelle neu vergebenen Berechtigungen gelten. Oft wird übersehen, dass  von oben auch Systemberechtigungen mitkommen, z.B. damit Administratoren und Backup arbeiten können, Auswertungen möglich sind oder Indexdienste die Informationen durchsuchbar machen.
  • Deny-Rechte
    Der zweite Irrweg ist einfach die unerwünschten Berechtigungen durch ein DENY zu blockieren. Denken Sie daran, dass ein explizites ALLOW ein vererbtes DENY überstimmt aber schon eine Ebene darunter wieder beide Berechtigungen vererbt sind und damit das DENY gewinnt. Wenn ein Benutzer dann in einer "ALLOW-Gruppe" und einer DENY-Gruppe Mitglied ist, fallen solche ungeeignete Konfigurationen zumindest schneller auf. Sie stören aber auch die Administration.

Beide Fehler werden von Administratoren gerne durch Übernahme des Besitz gelöst, was andere Probleme mit sich bringt.

Sometimes permissions are hosed and access is denied, even if you are the mighty administrator. In this case, you cannot even read the existing ACL. Of course, the administrator can always take the ownership of an object, but this erases the existing ACL of the object. This is bad because you cannot determine by the ACL the people who need to have access.
Quelle: https://learn.microsoft.com/en-us/archive/blogs/fieldcoding/ntfssecurity-tutorial-2-managing-ntfs-inheritance-and-using-privileges#using-privileges

Hier ist es besser mit dem "Backup and Restore Files"-Recht an den NTFS-Rechten vorbeizugehen.

  • EFS-Encryption
    Dateien auf dem Server "verschlüsseln" und damit gegen unerwünschte Zugriffe schützen ist gut gemeint aber schlecht gemacht. Die Datei wird beim Schreiben mit für die gerade berechtigten Personen und Gruppen verschlüsselt aber spätere Änderungen der Berechtigungen erlauben keinen Zugriff für die neu hinzugekommenen Personen. Ich hoffe, sie haben einen "RecoveryKey" vom ersten Tag an hinterlegt. Für ein Systembackup oder Imagebackup ist die Sicherung selbst kein Problem aber ein Restore auf andere Systeme oder eine Migration sind deutlich erschwert oder sogar unmöglich.
  • SID-History
    Vielleicht hat ihr Dateisystem schon einmal eine Migration durchlaufen und die SIDs in den ACLs sind gar nicht die primären SIDs der Gruppen und Benutzer sondern die SIDs früherer Domains, die als SIDHistory weiter an den Benutzern mitgeführt und nie ersetzt wurden. Eine Migration muss auch darauf Rücksicht nehmen, wenn Sie es denn frühzeitig erkannt haben.
  • Servernamen statt DFS und Kerberos
    Ich liebe DFS, weil es den physikalischen Servernamen aus den Pfaden entfernt und zumindest die Domain als "Virtualisierung" erlaubt. Wenn Benutzer sich aber mit Servernamen verbinden, der sich mit einem Umzug verändert, dann haben Sie viel Arbeit nicht nur "NET USE"-Laufwerke anzupassen sondern auch die unzähligen Verknüpfungen über UNC-Pfade.

Das sind die aus meiner Sicht nervigsten Hindernisse zur Migration von Freigaben und Dateien zwischen Servern oder Forests.

SID-History oder Add, Replace, Remove

Wer schon einmal mit ADMT gearbeitet hat, kennt von dort die Funktion auch NTFS-Rechte zu bearbeiten.

ADMT migriert Benutzer und Gruppen zwischen Domains. Damit Sie mit ADMT diese Funktion nutzen können müssen Sie diese Identitäten natürlich auch mit ADMT migriert haben, damit die Zuordnungen in der SQL-Datenbank von ADMT liegen.

Natürlich können Sie bei der Migration von Benutzern und Gruppen in vielen Fällen die SID der Quelle an das Zielobjekt übertragen, aber eigentlich sollte dies nur eine temporäre Lösung sein. Besser ist es, auf möglichst allen Ressourcen die alten SIDs durch neue SIDs zu ersetzen.

Wenn die Benutzer und Gruppen aber über einige Zeit parallel genutzt werden, dann ist es einfacher in einem ersten Durchlauf die alten SIDs durch neue zu ersetzen und nach Abbau der alten Domain im einem zweiten Durchlauf die alten SIDs zu entfernen. Alternativ warten Sie einfach darauf, bis die Server nach Ablauf ihrer Lebensdauer ersetzt und migriert werden und sie in dem Zuge eine "richtige" Berechtigungsverwaltung aufbauen.

ACL-Tools

Rechte addieren, ersetzen oder entfernen geht natürlich auch mit anderen Tools. Schon seit NT4/Windows 2000 gibt es Kommandozeilenprogamme wie CACLS.EXE, XCACLS.EXE etc., um Rechte zu lesen , zu setzen und zu löschen. Sie funktionieren meist sogar weiter aber der Ausgaben weiter verarbeiten möchte, nutzt besser PowerShell oder eigene Programme.

Die meisten Tools funktionieren für einzelne Aufrufe und manuelle Analysen ganz gut, aber abgesehen von Set-ACL/Get-ACL würde ich heute die einfachen EXE-Programme nicht für Automatisierungsaufgaben einsetzen, da die STDOUT-Ausgabe das String nicht einfach weiter zu verarbeiten ist.

Migrate-NTFSACLs

Um möglichst flexibel zu bleiben, habe ich mit eine CSV-Datei überlegt, in der bisherige und zukünftige Objekte hinterlegt sind und durch ein PowerShell-Script dann ein angegebener Pfad verarbeitet wird. Hier ein Beispiel um bestimmte Objekte aus der Quelle "MSXFAQ" mit den neuen Konten aus UCLABOR zu addieren.

OldIdentity,NewIdentity
MSXFAQ\User1,UCLABOR\userNeu
MSXFAQ\Group1,UCLABOE\GroupNeu

Die "OldIdentity" kann natürlich auch eine SID sein und die NewIdentity muss nicht in einem anderen Forest sein, sondern könnte auch in der gleichen Domain sein. Das Skript muss die SecurityIdentifier nur auflösen können.

Die CSV-Datei kann natürlich länger werden, wenn Sie alle Benutzer eines Forests addieren. Benutzerrechte gebe ich eigentlich nur auf das "Home-Directory" eines Benutzers. Ansonsten rate ich dringend dazu nur Gruppen zur Steuerung von Berechtigungen zu vergeben. Ein  PowerShell-Script könnte dann wie folgt aussehen:

Skripte auf Anfrage 

Das Skript erwartet mehrere Parameter, die im Code auch beschrieben sind.

 

Die Parameter sind eigentlich selbsterklärend. Das Skript gibt seine Aktionen auf der Konsole aus, so dass Sie mit "Start-Transcript" ein Protokoll schreiben lassen können. Zudem wird eine Ausgabe der Aktionen in die Ausgabe-Pipeline, so dass Sie die Ergebnisse z.B. in eine CSV-Datei weiterverarbeiten können. Zudem schreibt es die gleichen Aktionen auch in eine Protokolldatei.

Jeder Aufruf erzeugt eine neue Datei mit einem Zeitstempel, wenn Sie keinen eigenen Namen vorgeben. Vorne steht der Pfad oder die Datei und dann das aktuell berechtigte Objekt mit den Rechten. Das "NotFound" sagt, dass in der Parameterdatei keine passende Zeile mit einer SID gefunden wurde und daher am Ende ein "none" steht.

Einschränkungen

Das Skript "migrate-ntfsacl" ist ein Werkzeug und kein Produkt. Ich habe es für meine Einsätze bei Migrationen entwickelt und passe es auf Kunden entsprechend an oder erweitere es. Es gibt Sonderfälle, die ein Skript ebenfalls lösen könnte, die ich aber nicht implementiert habe. Damit bleibt der Code übersichtlicher und die Lösung muss mit dem Kunden auch immer erst beschrieben und umgesetzt werden.

  • Nur explizit vergebene ACLs
    Das Skript kümmert sich nicht nur noch vererbte ACLs
  • Keine Anpassung des "Besitzer"
    Das Skript ersetzt nicht den Besitzer (Owner) einer Datei oder Ordners. Es kann immer nur genau einen Owner geben und damit gibt es kein "Add" oder "Remove". Der Owner sollte auch nicht als Basis für einen Berechtigung genutzt werden. Bei einer sauberen Berechtigungsstruktur ist der Owner damit nur für Quotas relevant.
  • Keine Share-Berechtigungen
    Das Skript kümmert sich nicht um die Berechtigungen auf Freigaben. Es ist meist nicht viel Arbeit, die wenigen Freigaben eines Servers von Hand durchzuschauen und anzupassen.
  • Report nur Pfad und Identity
    Im "Report"-Mode werden nur explizit vergebene Berechtigungen ermittelt und dabei auch der Pfad, die Identity, Deny/Allow und die FileSystemRights protokolliert. Es ist kein "Analyse-Skript" um ausgeklügelte Reports zu  erstellen. Sie können es gerne erweitern, wenn Sie sich Gedanken über die spätere Auswertung der Daten gemacht haben. Für ein "Copy-SID" ist das nicht erforderlich.
    Eventuell ist das Skript Export-ACL für Reports interessant

Auch sonst hat das Skript natürlich noch Luft nach oben, z.B. Performancesteigerung zum Parallelisieren oder bessere Fehlerbehandlung.

Wenn Sie das Skript nutzen, dann testen Sie dies bitte ausführlich. Insbesondere die "Remove"-Funktion sollten mit Vorsicht verwenden, wenn Sie mit SIDHistory etc. arbeiten und die Auflösung einer SID zu einem Konto nicht funktioniert oder das Zielkonto auflöst.

Backup /Restore-Privilegien

Weiter oben haben ich schon das Problem beschrieben, wenn die Vererbung auf Verzeichnissen oder Dateien unterbunden wurden und damit im Extremfall auch ein Administrator keine Berechtigungen hat. Es reicht nicht, dass Sie ihr Dienstkonto in die entsprechende Gruppe addieren. Sie müssen dass Recht explizit noch anfordern und das geht nicht ohne Umweg über Systemaufrufe. Es gibt kein fertiges PowerShell-Commandlet dazu.

Aber mit etwas C#-Code in  PowerShell kann auch diese Hürde genommen werden. Der Schalter "backupPrivilege" erlaubt es dieses Recht einzufordern. Sie müssen dazu natürlich in der entsprechenden Sicherheitsgruppe sein und die PowerShell als Admin gestartet haben.

Testen können Sie Funktion sehr einfach mit einem Verzeichnis, bei dem Sie die Vererbung deaktivieren und alle Berechtigungen entfernen. Ohne das Recht bekommen Sie eine Fehlermeldung:

Ich lasse das Skript an der Stelle lieber abbrechen, damit Sie entsprechende Gegenmaßnahmen ergreifen und das Skript erneut starten können. Mit den entsprechenden Berechtigungen sehe ich, dass in den Verzeichnis "0" ACL-Einträge sind.

 

Das Arbeiten mit "SeBackupPrivilege" und "SeRestorePrivilege" hilft enorm, wenn Sie Berechtigungen auswerten und ggfls. auch ändern wollen.

Storage Migration Service (SMS)

"Gibt es da nicht auch was von .... Microsoft?" könnte eine Frage lauten. Tatsächlich liefert Microsoft schon sehr lange entsprechende Werkzeuge zur Migration von Dateien zwischen Servern, von Fremdsystemen oder zu Azure File Services mit. Früher gab es das "File Server Migration Toolkit", mit welchem Sie Dateien samt Berechtigungen auf neue Windows Server konsolidieren konnten. Anfang war sogar "NetWare" noch als Quelle möglich und FSMT hat alles versucht um auch die Berechtigungen zu übernehmen. Das Produkt ist eingestellt worden.

Mittlerweile gibt es als Bestandteil des Windows Admin Center die Funktion "Storage Migration Service (SMS)". Auch hiermit können Sie Dateien samt Freigaben von ein oder mehreren Servern auf einen neuen aktuellen Windows Server umziehen. Dabei werden nicht nur die Dateien kopiert, sondern auch Freigaben übernommen und zum Schluss kann das Tool sogar die Quellserver umbenennen und sich selbst den Namen des früheren Servers geben. So bleiben auch UNC-Pfade nach der Migration gültig. Darauf gehe ich im folgenden Abschnitt noch ein.

Die Aufgabenstellung ist dabei aber die Übertragung der Dateien von den Quell-Servern auf die neuen Server. Das geht sogar "Cross Domain" und "Cross Forest". Der Storage Migration Service patched oder verändert aber keine ACLs, auf den Dateien. Einzige bei der Verwendung lokaler Gruppen des Quellservers ersetzt er diese durch neue lokale Gruppen auf dem Zielserver. Die Mitgliedschaften müssen Sie aber selbst aktualisieren.

Der Storage Migration Service (SMS) ist daher keine Lösung, wenn sie einen bestehenden Server von einem Forest in einen anderen Forest umhängen und das Dateisystem beibehalten wollen. Aber vielleicht bringt ihre Migration ja auch eine Konsolidierung von Servern mit. Dann ist Storage Migration Service wieder ein Kandidat.

Windows Server 2008 End of Support - Migrating File Servers (Veröffentlicht 2020)
https://youtu.be/h-Xc9j1w144

Windows Server 2019 Storage Migration Service (English) (Veröffentlicht 2020)
https://www.youtube.com/watch?v=oSBWz3Q1s4o

Computername als Alias

Wenn ihre Anwender über den Servernamen auf Freigaben zugreifen und eine Reorganisation eine Veränderung des Servernamens und/oder Domainnamen bedeutet, dann könnte die Alias-Funktion von Windows Servern eine interessante Funktion sein. Ein Windows-Dateiserver ist nicht nur unter seinem primären Namen erreichbar, sondern kann mehrere zusätzliche Namen erhalten und darüber angesprochen werden. Das geht über den Befehl "NETDOM", z.B.:

netdom computername SV01 /add:SV01B.uclabor.de

Achtung: Geben Sie immer den FQDN an. Kurze Namen sind möglich, aber erscheinen nicht im DNS. Damit die neuen Namen direkt per DNS auflösbar sind, sollten Sie ein "ipconfig /registerdns" danach ausführen.   

Ich habe meinem Testserver 26 weitere Namen ohne Probleme zuweisen können und habe keine Quelle für eine Obergrenze gefunden.

Durch das Addieren eines zusätzlichen Namens werden mehrere Änderungen durchgeführt:

  • Addiert LanManServer: OptionalNames
    In der Registrierung wird der Namen unter "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\OptionalNames" eingetragen. Damit lernt der "Server"-Dienst, dass er auch über den alternativen Namen ansprechbar ist.
  • Addiert DNS: AlternateComputerNames
    Auch hier wird der Eintrag addiert HKLM\System\CurrentControlSet\Services\DNSCache\Parameters\AlternateComputerNames:REG_Multi_SZ. Dies hat direkte Auswirkungen auf die Funktion von "dynamischen DNS-Updates". Allerdings bekommt der DNS-Dienst dies nicht sofort mit. Bei mir hat ein "ipconfig /registerdns" erst den zusätzlichen Namen im DNS eingetragen.
  • AD Computer: ServicePrincipalName
    Jeder Computer, der Domainmitglied ist, hat ein Computerobjekt im Active Directory und über die Einträge im "ServicePrincipalName" stellt das Kerberos Distribution Center (KDC) entsprechende Kerberos Tickets (TGT) aus. Hier sehen Sie mein Computerkonto "sv01.uclabor.de" mit den weiteren Namen "sv01b.uclabor.de und sc01b@uclabor2.de". Der Namen kann also durchaus auch aus einer anderen Domain sein.
  • DNS-Eintrag
    Bein nächsten manuellen oder automatischen Update werden auch die DNS-Einträge addiert. Auch das kann in unterschiedlichen DNS-Zonen erfolgen. Sie können den Vorgabe mit "ipconfig /registerdns" beschleunigen. Es wird ein zweiter A-Record angelegt, so dass Kerberos auch den neuen Namen nutzt und kein CNAME.
    Wenn sie keine dynamischen DNS-Updates erlauben, müssen Sie diese manuell anlegen.

Für SMB und viele andere Dienste sind damit alle Vorarbeiten erfolgt. Beim Zugriff per TLS auf den neuen/alten Namen müssen Sie aber darauf achten, dass die Zertifikate ggfls. erweitert werden müssen.

Über diesen Weg können Sie sehr einfach einen Servernamen bei einer Migration in eine neue Domain überführen.

Die zusätzlichen Namen lassen sich über NETDOM auch wieder entfernen:

netdom computername SV01 /remove:SV01B.uclabor.de

Allerdings habe ich in meiner Testumgebung immer wieder gesehen, dass nicht alle DNS-Einträge in der DNS-Zone und vor allem die ServicePrincipalNames am Computerobjekt nicht sauber entfernt wurden. Eine Kontrolle ist also notwendig. 

Empfehlung

Es ist schwer, eine generelle Empfehlung zu geben, denn Ausgangspunkt für eine Migration ist die IST-Aufnahme der aktuellen Berechtigungen. Mein Beispiel-Skript ermittelt im "Report"-Mode nur alle explizit vergebenen Berechtigungen mit Pfad und Identity aber ohne weitere Details. Das reicht für einen ersten Überblick schon einmal aus.

Dennoch sollten Sie genau abwägen, ob sie bei dem Umzug des Servers in eine neue Domain oder neuen Forest einfach zu den alten SIDs die passenden neuen SIDs addieren oder nicht besser eine neue Berechtigungs- und Verzeichnisstruktur aufbauen. Dabei können Sie ihr Konzept zur Vergabe von Berechtigungen über Gruppen, die Festlegung von Besitzern und die Steuerung der der Inhalte und Nutzung durch Quotas und Richtlinien umsetzen.

Leider erlebe ich aber häufiger den Ansatz, dass man erst mal nichts ändern sollte und schon die Umstellung der Domains und Anmeldung die Anwender überfordern könnte. Ob Sie dann aber jemand später noch einmal das Thema angehen, steht auf einem anderen Blatt. Es könnte ja ein anderes Projekt nachfolgen, um z.B. Dokumente auf Sharepoint oder andere leistungsfähigere Systeme zu migrieren oder sie haben wirklich einen Security Vorfall aufgrund von "Oversharing" oder "Missbrauch" und können über den Hebel dann nachträglich ihr Konzept umsetzen.

Wenn Sie Unterstützung bei der Planung und Umsetzung ihrer Migration benötigen, dann können Sie meine Kollegen bei Net at Work und mich gerne ansprechen. Siehe

Weitere Links