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

 

Ü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.

Über MyWorkDrive aktivieren

Neu! Ab MyWorkDrive-Server 6.3 prüfen integrierte Skripts, ob die Delegierung aktiviert ist, und bieten an, die Delegierung direkt von MyWorkDrive für Sie festzulegen.

Diese Prüfung und das Korrekturangebot sind sowohl auf der Registerkarte „Freigaben“ als auch im neuen verfügbar Gesundheits-Dashboard (ebenfalls ein neues Feature von 6.3)

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 Delegationswarnung als auch eine Schaltfläche angezeigt, die Sie auffordert, eine Delegation hinzuzufügen.

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 diejenigen, die eine bestimmte Form der Delegierung erfordern, wie z. B. KCD. Wenn die automatisierte Methode für Sie nicht funktioniert, überprüfen Sie bitte die zusätzlichen Optionen unten, um die für Ihre Umgebung am besten geeignete Methode zu finden.

Active Directory

Aktive Verzeichnisse Benutzer und Computer

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 bei der Delegierung an alle Server vertrauen (nur Kerberos)“ Wir stark plädieren dafür, einen Least Privileged Access-Ansatz zu wählen, indem Sie die Server und Dienste wie oben beschrieben angeben. Weitere Informationen zum Schutz Ihres Active Directory und zu Delgationsrisiken 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, CIFS über Powershell eine eingeschränkte Delegierung zuzuweisen, es wird jedoch empfohlen, die GUI-Methode über ADUC zu verwenden.

Um dies über Powershell zu tun, müssen Sie eine Liste der Dienstprinzipalnamen (SPNs) von FILESERVER in den MyWorkDrive-Serverkonten angeben.

Im folgenden Beispiel ersetzen Sie „FILESERVER“ durch den Netbios-Namen Ihres Dateiservers und „MWDSERVER“ durch den Netbios-Namen Ihres MyWorkDrive-Servers.

Um die Liste der SPNs abzurufen, können Sie das Cmdlet Get-ADComputer verwenden und die Eigenschaft servicePrincipalName von FILESERVER anzeigen

Get-ADComputer FILESERVER -Eigenschaften servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName |format-list

Sie erhalten eine Liste mit Einträgen wie
host/FILESERVER
host/FILESERVER.domain.tld

Dann müssen Sie das Cmdlet „Set-ADComputer“ mit dem Parameter „msDS-AllowedToDelegate“ verwenden und die Werte für den Abschnitt „msDS-AllowedToDelegateTo“ durch die SPNs des FILESERVER ersetzen

Get-ADComputer -Identity MWDSERVER | Set-ADAccountControl -TrustedToAuthForDelegation $true
Set-ADComputer -Identity MWDSERVER -Add @{'msDS-AllowedToDelegateTo'=@('cifs/FILESERVER','cifs/FILESERVER.domain.tld')}

Wenn Sie über mehr als einen Dateiserver verfügen, können Sie weiterhin SPNs für alle Dateiserver mit derselben Syntax hinzufügen.
Wenn Sie mehr als einen MyWorkDrive-Server haben, müssen Sie den Befehlssatz für jeden MyWorkDrive-Server ausführen.

Testen

Um zu testen, welche Delegierung mit Powershell vorhanden ist, erhalten Sie mit diesem Befehl eine Liste der Dateiserver, die Ihrem MyWorkDrive-Server für die Delegierung vertrauen.

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

* Beachten Sie, dass Active Directory mindestens 15 Minuten benötigt, um diese Änderungen auf seine Datenbank anzuwenden und zu replizieren – Warten Sie mindestens 15 Minuten, bevor Sie mit dem Testen des Zugriffs beginnen.

Eingeschränkte Kerberos-Delegierung

Einige Umgebungen erfordern möglicherweise die alternative Konfigurationsmethode Kerberos Constrained Delegation (KCD) .

Für Kunden mit mehreren Domänen oder Kunden, 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. Einige Kunden in Hochsicherheitsumgebungen oder bei der Verwendung von File-Serving-Appliances benötigen möglicherweise auch eine ressourcenbasierte eingeschränkte Delegierung.

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 tatsächlichen Dateifreigaben hostet, die dem MyWorkDrive-Server vertrauen, einen der folgenden Powershell-Befehle aus: Dabei ist $MyWorkDriveServer der Name des MyWorkDrive-Servers und $FileServer der Name des Dateiservers, der Ihre Domäne auf dem MyWorkDrive-Server eingibt befindet sich in Ihrer Abfrage in der Suchbasis oder unter Verwendung des angegebenen Domänencontrollers, 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

 

Azure AD Domain Services-Speicherbenutzerkonto

Um die Delegierung zu aktivieren, müssen wir den unten stehenden Powershell-Befehl verwenden, um das Speicherbenutzerkonto so einzustellen, dass es dem MyWorkDrive-Servercomputer vertraut, um die Verwendung von KCD zu delegieren. Außerdem müssen wir das Computerkonto des MyWorkDrive-Servers und die Benutzerkonten für die Azure-Dateifreigaben aus den Standard-OUs in eine benutzerdefinierte OU verschieben. Einzelheiten finden Sie in diesen Microsoft-Artikel

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.

Powersell-Einstellungen
$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

Beginnen Sie mit MyWorkDrive Server 5.4 oder höher und führen Sie die Tests im MyWorkDrive Server Admin Panel auf jeder Freigabe mit unserem integrierten Testtool durch.

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 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 korrekt 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 hinweisen, 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.