Delegierungseinrichtung für ADFS/SAML-, Datei- und DFS-Server in Active Directory

Die Anweisungen in diesem Artikel gelten nur für MyWorkDrive-Installationen, die Active Directory für Benutzeridentitäten und SMB-Dateifreigaben verwenden. Bei Verwendung von Entra ID als Benutzerverzeichnis ist keine Delegierung erforderlich.

 

 

Überblick

Dieser Artikel beschreibt die Schritte zum Einrichten der Delegierung, damit ADFS/SAML ordnungsgemäß mit allen Back-End-Datei- und DFS-Servern in Active Directory funktioniert. Wenn sich Dateifreigaben auf einem anderen Server als dem MyWorkDrive-Server (MWD) befinden, über DFS erreicht werden oder Benutzer mit ADFS/SAML authentifiziert werden, ist es erforderlich, dass der MyWorkDrive-Server wird von allen Dateiservern und DFS-Servern für die Delegierung als vertrauenswürdig eingestuft.

Arten der Delegation

Es gibt zwei Arten der Delegation, die Sie mit MyWorkDrive verwenden können.

• Eingeschränkte Delegation/Eingeschränkte Kerberos-Delegierung oder KCD
• Ressourcenbasierte eingeschränkte Kerberos-Delegierung (RBKCD)

Eingeschränkte Delegation oder eingeschränkte Kerberos-Delegierung (KCD) können über die ADUC-Benutzeroberfläche oder über Powershell festgelegt werden. Dies ist der häufigste Typ und wird in Fällen verwendet, in denen Sie über eine einzelne Domäne ohne externe Vertrauensstellungen verfügen.
Mit der eingeschränkten Delegation beschränken Sie den Zugriff auf einen bestimmten Dienst (im Fall von MyWorkDrive CIFS).
Mit Kerberos Constrained Delegation (KCD) beschränken Sie den Authentifizierungstyp auf Kerberos und den Dienst auf CIFS.

Die ressourcenbasierte eingeschränkte Kerberos-Delegierung kann nur über Powershell festgelegt werden. Mit RBKCD geben Sie zusätzlich an, welche Server (Ressourcen) Zugriffsanfragen zulassen.
Es wird am häufigsten verwendet, wenn eine externe Vertrauensstellung verwendet wird (d. h. es gibt Ressourcen in zwei verschiedenen Domänen, auf die Sie zugreifen, z. B. ein MyWorkDrive-Server und Benutzer in Domäne1, mit Dateifreigaben in Domäne2). Bei einem Trust muss den Ressourcen ausdrücklich mitgeteilt werden, von wo sie Autorisierungsanfragen entgegennehmen sollen. Sie akzeptieren keine domänenübergreifenden Autorisierungsanfragen, es sei denn, sie wurden ausdrücklich autorisiert. Weitere Informationen zur Trust-Konfiguration finden Sie unter Dieser Beitrag.

In diesen Artikeln erfahren Sie mehr über die Arten der verschiedenen Delegation
Übersicht über die eingeschränkte Kerberos-Delegierung
Machen Sie den zweiten Hop in PowerShell Remoting, das einen guten Überblick über die Anwendungsfälle für KCD und RBKCD bietet
Kerberos-Delegation, Eine gute Diskussion der KCD/RBKCD-Implementierung

In diesen Artikeln werden andere Formen der Authentifizierung erwähnt, z. B. credSSP und JEA, die nicht mit MyWorkDrive verwendet werden, sowie die uneingeschränkte Delegation, die wir aus Sicherheitsgründen nicht empfehlen.

Über MyWorkDrive aktivieren

Ab MyWorkDrive-Server 6.3 prüfen integrierte Skripts, ob die eingeschränkte Delegation aktiviert ist, und bieten an, die Delegation direkt von MyWorkDrive aus für Sie einzurichten.

Diese Prüfung und das Angebot zur Behebung sind sowohl auf der Registerkarte „Freigaben“ als auch in der neuen Version verfügbar Gesundheits-Dashboard (ebenfalls ein neues Feature von 6.3)
Diese Funktion funktioniert mit eingeschränkter Delegation, die am häufigsten über die ADUC-basierte GUI-Einstellung der Delegation festgelegt wird. KCD/RBKCD wird nicht erkannt und die Warnungen können in diesen Fällen ignoriert werden.

In der Liste der Freigaben sehen Sie möglicherweise ein Warnsymbol, dass eine Delegierung erforderlich ist, aber für eine oder mehrere bestimmte Freigaben nicht richtig eingestellt ist.

 

Wenn Sie auf die Freigabe klicken, um sie zu bearbeiten, wird sowohl eine Delegierungswarnung als auch eine Schaltfläche mit der Aufforderung „Delegierung hinzufügen“ angezeigt.

Wenn Sie auf die Schaltfläche „Delegation hinzufügen“ klicken, wird eine Meldung zu den Kontoanforderungen angezeigt – Sie müssen als Domänenadministrator bei MyWorkDrive angemeldet sein, um die automatische Delegierungsfunktion verwenden zu können. Wenn das Konto, mit dem Sie MyWorkDrive verwalten, kein Domänenadministrator ist, können Sie die Delegierung mit einem der unten beschriebenen Schritte aktivieren.

 

Die integrierten Skripts, die prüfen, ob die Delegierung aktiviert ist, und anbieten, die Delegierung für Sie direkt in MyWorkDrive festzulegen, werden ebenfalls im neuen angezeigt Gesundheits-Dashboard mit dem gleichen Angebot, die Delegationsfunktion einzustellen.

Beachten Sie, dass die automatisierte Methode möglicherweise nicht für alle Umgebungen funktioniert, insbesondere für solche, die eine bestimmte Form der Delegation wie KCD erfordern. Wenn die automatisierte Methode für Sie nicht funktioniert, prüfen Sie bitte die folgenden zusätzlichen Optionen, um die für Ihre Umgebung am besten geeignete Methode zu finden.

Eingeschränkte Delegation

Festlegen einer eingeschränkten Delegierung über Active Directory-Benutzer und -Computer der ADUC-Benutzeroberfläche

Die häufigste Methode zum Konfigurieren der Delegierung erfolgt über die Eigenschaften des MyWorkDrive-Servers in Active Directory-Benutzer und -Computer. Konfigurieren Sie die Active Directory-Delegierung auf dem Computerobjekt MyWorkDrive-Server, um beliebige Dateiserver und DFS-Server in Ihrer Organisation hinzuzufügen.

– Von einem Domänencontroller – Server-Manager – Tools – Active Directory-Benutzer und -Computer – Computer – {Computer auswählen, auf dem MWD installiert ist} – Eigenschaften – Delegierung – Diesem Computer nur für die Delegierung an bestimmte Dienste vertrauen – Beliebiges Authentifizierungsprotokoll verwenden – Hinzufügen – Benutzer oder Computer – {Computer auswählen, die erforderliche Netzwerkfreigaben und Computer mit installierter DFS-Rolle enthalten} – OK – Verfügbare Dienste – cifs auswählen – OK

Wir stark empfehle dich weiter NICHT AUSWÄHLEN die Option „Diesem Computer für die Delegierung an beliebige Server vertrauen (nur Kerberos)“. (uneingeschränkte Delegation) Wir stark Wir empfehlen Ihnen, einen Ansatz mit dem geringsten privilegierten Zugriff zu wählen, indem Sie die Server und Dienste wie oben beschrieben angeben (eingeschränkte Delegation). Weitere Informationen zum Schutz Ihres Active Directory und zu Delegationsrisiken finden Sie unter Petri.com und ADSecurity.org

Konfigurationsbeispiel, damit MWD der Delegierung über File-Server1 und DFS-Server1 vertrauen kann: – MWD installiert auf Computer MYWORKDRIVE-SERVER1 – Network File Share Server: FILE-SERVER1 – DFS-Server: DFS-SERVER1

Mit Powershell

Es ist auch möglich, die auf CIFS beschränkte Delegation über Powershell zuzuweisen, es wird jedoch empfohlen, die GUI-Methode über ADUC zu verwenden.

Dieses Skriptbeispiel erstellt ein Array aller Dateiserver und ermöglicht die Delegierung an diese spezifischen Dateiserver über das CIFS-Protokoll an die MyWorkDrive-Server.

—

# Importieren Sie das ActiveDirectory-Modul
Import-Modul ActiveDirectory

# Erstellen Sie ein Array und weisen Sie es einer Variablen zu. Fügen Sie in der @-Komponente die Namen Ihrer Dateiserver hinzu bzw
#DFS-Hostserver.
$TargetComputers = @(„FileShare1“, „DFSshare1“)

# Durchlaufen Sie jedes Element des Arrays und konfigurieren Sie die Delegation
ForEach ($Computer in $TargetComputers) {

# Stellen Sie eine Verbindung zum MyWorkDrive-Server her – ersetzen Sie den Ausdruck „MWDServer“ durch den NetBIOS-Namen Ihres Servers
#MYWorkDrive-Server. Wenn Sie mehr als 1 haben, führen Sie das gesamte Skript mehr als einmal aus.
Get-ADComputer -Identity MWDServer

# Fügen Sie den CIFS-SPN des aktuellen Computers zur Liste der Dienste hinzu, an die FileServer delegieren kann
Set-ADComputer -Identity MWDServer -Add @{'msDS-AllowedToDelegateTo'= „cifs/$Computer“}
}

—

Testen

Um mit Powershell zu testen, welche Delegierung vorhanden ist, erhalten Sie mit diesem Befehl eine Liste der Dateiserver, die Ihrem MyWorkDrive-Server für die Delegierung vertrauen. Ersetzen Sie im folgenden Skript „MWDServer“ durch den NetBIOS-Namen Ihres MyWorkDrive-Servers.

—

Get-ADComputer MWDSERVER -Properties msDS-AllowedToDelegateTo,Displayname | wählen Sie Anzeigename -ExpandProperty msDS-AllowedToDelegateTo | Formatliste

—

*Beachten Sie, dass es mindestens 15 Minuten dauert, bis Kerberos-Tickets wiederverwendet werden, und möglicherweise länger, bis Active Directory die Änderungen verbreitet. Warten Sie mindestens 15 Minuten, bevor Sie mit dem Testen des Zugriffs beginnen.

Möglicherweise können Sie die Argumente „purge“ und „–li 0x3e7“ mit dem verwenden klist Befehl auf den Dateiservern und MyWorkDrive-Servern, um den Recycling-Teil zu beschleunigen, aber wir haben festgestellt, dass er nicht besonders effektiv ist.

Ressourcenbasierte eingeschränkte Kerberos-Delegierung

In einigen Umgebungen ist möglicherweise die alternative Konfigurationsmethode Resource Based Kerberos Constrained Delegation (RBKCD) erforderlich.

Für Kunden mit mehreren Domains (Domänenvertrauensstellungen) oder diejenigen, die ihr Active Directory in Azure AD Domain Services hosten (dies ist nicht dasselbe wie Azure AD), muss die Delegierung mithilfe der ressourcenbasierten eingeschränkten Delegierung in Powershell aktiviert werden. RBKCD ist für vertrauenswürdige Domänen erforderlich, da es die einzige sichere Delegationsmethode ist, die Double-Hop-Authentifizierung unterstützt. Weitere Details finden Sie hier Microsoft-Artikel. Einige Kunden in Hochsicherheitsumgebungen oder bei der Verwendung von File-Serving-Appliances benötigen möglicherweise auch eine ressourcenbasierte eingeschränkte Delegation.

Powershell-Konfigurationsschritte für Server 2012-Domänen oder höher finden Sie im Artikel von Microsoft Informationen zum Aktivieren der eingeschränkten Kerberos-Delegierung (KCD) in einer verwalteten Domäne und So konfigurieren Sie die Computerdelegierung mit Powershell.

Ein Beispiel für einen MyWorkDrive-Serverbefehl für einen Dateiserver und einen MyWorkDrive-Server lautet wie folgt:

 

Einzelne Domäne:

Set-ADComputer MyWorkDriveServer -PrincipalsAllowedToDelegateToAccount (Get-ADComputer FileServer)

 

Mehrere Domänen, in denen sich MyWorkDrive-Server, -Benutzer oder -Ressourcen in verschiedenen Domänen befinden:

Führen Sie auf dem Windows-Server, der die eigentlichen Dateifreigaben hostet und dem MyWorkDrive-Server vertraut, einen der folgenden Powershell-Befehle aus: Dabei ist $MyWorkDriveServer der Name des MyWorkDrive-Servers und $FileServer der Name des Dateiservers, der Ihre Domäne eingibt Der MyWorkDrive-Server befindet sich in Ihrer Abfrage in der Suchbasis oder verwendet den angegebenen Domänencontroller, bei dem der MyWorkDrive-Server Mitglied ist:

Angegebener Domänencontroller:

$MyWorkDriveServer= Get-ADComputer -Identity MYWORKDRIVE-SERVER -server mwf-dc.mwf.local

$FileServer= Get-ADComputer -Identity „FILE-SERVER“ -server mwf-dc.mwf.local

$FileServer2= GetADComputer – Identifizieren Sie „FILE-SERVER2“ – Server mwf2.dc.mwf2.local

Set-ADComputer ($FileServer),($FileServer2) -PrincipalsAllowedToDelegateToAccount $MMyWorkDriveServer

Suchbasis:

$MyWorkDriveServer= Get-ADComputer -Filter {Name -eq „MYWORKDRIVE-SERVER“} -SearchBase „DC=MWF,DC=local“ -Server „mwf.local“

$FileServer= Get-ADComputer -Filter {Name -eq „FILE-SERVER“} -SearchBase „DC=MWF,DC=local“ -Server „mwf.local“

Set-ADComputer $FileServer -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer

 

Mehrere/vertrauenswürdige Domänencontroller und mehrere MyWorkDrive-Server:

Es ist wichtig zu beachten, dass das Ausführen des Befehls Set-ADComputer in PowerShell löschen eventuell vorhandene Delegationseinträge und ersetzen sie mit Ihren neuen Einträgen. Wenn Sie bereits eine Delegierung für vorhandene Dienste eingerichtet haben, kann dies unerwünschte Folgen haben. Mithilfe des PowerShell-Beispielskripts suchen Sie zunächst nach vorhandenen Delegierungseinstellungen und schließen diese Server in den Delegierungseintrag ein. Dabei bleiben die vorhandenen Delegierungseinstellungen erhalten, während Sie neue für Ihren MyWorkDrive-Server hinzufügen.

Sie können eine ZIP-Datei dieses PS1-Skripts herunterladen Hier.

Entra ID Domain Services-Speicherbenutzerkonto

Um die Delegierung mit Entra ID Domain Services und einem Storage-Benutzerkonto zu aktivieren, müssen wir den folgenden PowerShell-Befehl verwenden, um das Storage-Benutzerkonto so einzurichten, dass es dem MyWorkDrive-Servercomputer vertraut und die Delegierung mithilfe von KCD erlaubt. Wir müssen außerdem das MyWorkDrive-Servercomputerkonto und die Benutzerkonten für die Azure-Dateifreigaben aus den Standard-OUs in eine benutzerdefinierte OU verschieben. Details finden Sie unter diesen Microsoft-Artikel. Die Delegierung funktioniert nicht, wenn die Konten in Active Directory nicht aus den Standard-Organisationseinheiten verschoben werden.

OU
Die Konten für den MyWorkDrive-Servercomputer und die Benutzer von Azure File Shares müssen sich in einer benutzerdefinierten Organisationseinheit befinden, in der Sie über Berechtigungen zum Konfigurieren von ressourcenbasiertem KCD verfügen. Sie können keine ressourcenbasierte KCD für ein Computerkonto im integrierten AAD-DC-Computercontainer konfigurieren.

PowerShell-Befehle
$ImpersonatingAccount = Get-ADComputer -Identity
Set-ADUser -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Beachten Sie, dass Sie für das StorageUserAccount möglicherweise den SAM-Kontonamen und nicht den Namen/allgemeinen Namen verwenden müssen. Suchen Sie den SAM-Kontonamen als Pre-Windows 2000-Namen auf der Kontoregisterkarte der Elemente in ADUC oder mit Get-ADUser in Powershell

Beispiel Powershell

MWD01 – Name des MyWorkDrive-Servers
SA_81e0bcb563 – SAMAccountName der Azure-Dateifreigabe

$ImpersonatingAccount = Get-ADComputer -Identity MWD01
Set-ADUser SA_81e0bcb563 -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

 

Testen

Um die Delegierung zu überprüfen, führen Sie den folgenden PowerShell-Befehl aus:

Get-ADComputer $MyWorkDriveServer -Properties * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity

Oder

Ab MyWorkDrive Server 5.4 oder höher können Sie die Tests im MyWorkDrive Server Admin-Bereich auf jeder Freigabe mithilfe unserer integrierten Funktion ausführen Testtool teilen, anstatt sich als Benutzer bei einem Client anzumelden.

Sonderfälle – DFS und AzureFiles

DFS

Wenn Sie DFS mit SSO und MyWorkDrive verwenden, müssen Sie die Delegierung für den MyWorkDrive-Server sowohl für die DFS-Computer/Hosts als auch für die Dateifreigabeserver einrichten.

IE, wenn Sie die folgenden Server haben

DFS1 DFS2

Konfiguriert, um Dateien von den folgenden Dateiservern (Windows oder AD Joined Storage Devices) FileShareSanJose FileShareHouston FileShareNewYork freizugeben

Dann sollten alle fünf AD-Mitglieder auf der Registerkarte „AD-Delegierung“ des MyWorkDrive-Servers als zum Delegieren über CIFS genehmigt angezeigt werden

Azure-Dateien

Wenn Sie unsere erfolgreich abgeschlossen haben Einrichtungsanleitung zur Verwendung von Azure Files mit MyWorkDrive, ist Ihr Azure Files Storage-Konto a Domänenmitglied. Dieses Domänenmitglied muss der Delegierung für den MyWorkDrive-Server hinzugefügt werden, damit SSO dieses Laufwerk Benutzern ordnungsgemäß als Freigabe präsentieren kann.

Fehlerbehebung

Wenn Ihre Freigaben leer angezeigt werden, wenn sich Benutzer über SSO anmelden, ist die Delegierung wahrscheinlich nicht richtig eingerichtet. Wenn Sie der Meinung sind, dass Sie die Delegierung über KCD oder Active Directory richtig eingerichtet haben, können Sie Powershell verwenden, um zu testen, ob der Dateifreigabeserver/die Appliance die Delegierung korrekt akzeptiert. Dadurch erfahren Sie, ob der angemeldete Benutzer auf Dateien und Ordner in der delegierten Dateifreigabe zugreifen kann.

Sie können ein sehr einfaches Powershell-Skript verwenden, um zu testen, ob die Delegation richtig eingestellt ist, indem Sie eine Technik verwenden, die als „Double Hop“ bekannt ist. Weitere Informationen zu diesem Test finden Sie unter https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/ Um diesen Test durchzuführen, benötigen Sie 3 Computer in Ihrem Active Directory

• Client – dies kann jeder in eine Domäne eingebundene Computer sein; B. eine Windows 10-Workstation. Sie führen den Powershell-Befehl auf dem Computer aus.
• MyWorkDrive Server – der Server, der per Delegierung auf die Freigabe zugreifen können soll
• Dateiserver – der Server, der für die Delegierung auf dem MyWorkDrive-Server eingestellt ist.

Sie müssen auch den Freigabepfad einer Freigabe auf dem Dateiserver kennen, der Dateien enthält, auf die der angemeldete Benutzer zugreifen kann. Der Powershell-Befehl lautet Invoke-Command -ComputerName $MyWorkDriveServerName -ScriptBlock {Get-ChildItem -Path \\$FileServer\ShareName } Sie ersetzen $MyWorkDriveServerName durch den Netzwerknamen Ihres MyWorkDrive-Servers. Sie ersetzen $FileServer\ShareName durch den Dateiserver und die Freigabe, die Sie testen möchten. Die Freigabe sollte Dateien enthalten, auf die der Benutzer Zugriff haben soll. Und führen Sie den Befehl von der Client-Arbeitsstation aus Beispiel In unserem Beispiel testen wir die Delegierung an eine Linux-Samba-Freigabe von zwei verschiedenen MyWorkDrive-Servern. Für einen MyWorkDrive-Server ist eine Delegierung eingerichtet, für den anderen nicht. Wir testen von einem Windows 10-Client in der Domäne. Delegierung nicht eingerichtet In diesem Test testen wir die Delegierung auf einem Server, auf dem wir absichtlich keine Delegierung eingerichtet haben, und erwarten einen Fehler.

• MyWorkDrive-Server: mwf-scott6
• Dateiserver: ubuntu-samba
• Teilen: alle

Führen Sie Powershell auf dem Windows 10-Domänenmitglied aus und führen Sie den folgenden Befehl aus Invoke-Command -ComputerName mwf-scott6 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } Die Ergebnisse, die wir erhalten, sind: Ein Fehler, dass der Dateipfad nicht existiert. Die Delegierung hat nicht funktioniert und unser Benutzer konnte nicht auf die Freigabe zugreifen. In diesem Szenario wird die Freigabe leer angezeigt, wenn sich der Benutzer über SSO bei MyWorkDrive anmeldet. Dies ist das erwartete Ergebnis, da wir keine Delegierung eingerichtet haben. Es kann auch darauf hindeuten, dass Ihr Dateiserver/Ihre Appliance keine Delegierung akzeptiert, wenn die Einrichtung korrekt ist. Delegierung einrichten In diesem Test testen wir die Delegierung auf einem Server, auf dem die Delegierung korrekt eingerichtet ist

• MyWorkDrive-Server: mwf-scott5
• Dateiserver: ubuntu-samba
• Teilen: alle

Führen Sie Powershell auf dem Windows 10-Domänenmitglied aus und führen Sie den folgenden Befehl aus Invoke-Command -ComputerName mwf-scott5 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } Die Ergebnisse, die wir erhalten, sind: Eine Liste der Dateien und Ordner im Verzeichnis. Die Delegierung hat funktioniert und unser Benutzer konnte auf die Freigabe zugreifen.

November 2021 Windows-Update

Patches, die von Microsoft während des Patch Tuesday im November 2021 am 9. November veröffentlicht wurden, verursachen leere Freigaben bei der Anmeldung mit SSO, ähnlich wie die Delegierung nicht korrekt aktiviert wird. Das Problem wurde Ende November mit Patches behoben und schließlich in den Dezember- und Januar-Rollups behoben.

Ab Mitte 2022 sollten keine weiteren Fälle davon vorliegen, da diese Aktualisierungen nicht mehr relevant sind.

Wir nehmen diese Informationen zu Archivierungszwecken auf

Wenn Logins plötzlich leer auf einer bestehenden MyWorkDrive-Installation erscheinen, die zuvor einwandfrei funktioniert hat, müssen Sie den fehlerhaften Patch erneut installieren. Einzelheiten finden Sie in diesem Artikel.

Wenn Sie SSO zum ersten Mal auf Ihrem MyWorkDrive-Server einrichten, Weitere Informationen zum Anwenden des Fixes finden Sie im Artikel an Ihre Domänencontroller, zusätzlich zur Konfiguration der Delegierung wie unten beschrieben.
Der über Windows Update bereitgestellte Fix für den Patch muss manuell angewendet werden. Ohne das Hinzufügen des Fixes für den Windows Update-Patch führen Anmeldungen zu leeren Freigaben.