fbpx

Wie können wir Ihnen heute helfen?

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

Du bist da:
< Zurück

 

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

Enable via MyWorkDrive

New! As of MyWorkDrive server 6.3, built in scripts will audit to see if delegation is enabled and offer to set delegation for you directly from MyWorkDrive.

This audit and offer to fix is available on both the shares tab and in the new Health Dashboard (also a new feature of 6.3)

On the list of shares, you may note a warning icon that delegation is required, but that is is not correctly set for a given share or shares.

 

Clicking to edit the share will show both a delegation warning AND a button prompting you Add Delgation.

Clicking the “Add Delegation” button will display a message about account requirements – you must be logged in to MyWorkDrive as a Domain Administrator to use the automated delegation feature. If the account you administer MyWorkDrive with is not a domain administrator, you can continue enabling delegation with one of the steps outlined below.

 

The built in scripts that audit to see if delegation is enabled and offer to set delegation for you directly in MyWorkDrive also appear in the new Health Dashboard with the same offer to set delegation feature.

Note that the automated method may not work for all enviornments, particuarly those which require a specific form of delegation such as KCD. If the automated method does not work for you, please review the additional options below for the most appropriate method for your enviornment.

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

To enable delegation we need to use the powershell command below to set the Storage User account to trust the MyWorkDrive server computer as allowed to delegate to using KCD. We must also move the MyWorkDrive server computer account and the user account(s) for the Azure File Shares out of default OUs to a custom OU. Details are available in this Microsoft article

OU
The accounts for the MyWorkDrive server computer and the Azure File Shares user(s) must be in a custom OU where you have permissions to configure resource-based KCD. You can’t configure resource-based KCD for a computer account in the built-in AAD DC Computers container.

Powersell Settings
$ImpersonatingAccount = Get-ADComputer -Identity
Set-ADUser -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Note that for the StorageUserAccount, you may be required to use the SAM Account Name, not the Name/Common Name. Find the SAM Account Name as the Pre windows 2000 name on the items’ account tab in ADUC or with Get-ADUser in Powershell

Example Powershell

MWD01 – name of the MyWorkDrive server
SA_81e0bcb563 – SAMAccountName of the Azure File Share

$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 released by Microsoft during November 2021’s Patch Tuesday on 9 November cause blank shares on login with SSO in a simliar way to not correctly enabling delegation. The issue was resolved with patches in late November, and finally fixed in the December and January Roll Ups.

As of mid 2022, no further cases of this should be presenting, as those updates are no longer relevant.

We include this information for archival purposes

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.