Hoe kunnen we u vandaag helpen?
Delegatie instellen voor ADFS/SAML-, bestands- en DFS-servers in Active Directory
Overzicht
In dit artikel worden de stappen voor het instellen van delegaties beschreven om ADFS/SAML correct te laten werken met alle back-end-bestands- en DFS-servers in Active Directory. Wanneer bestandsshares zich op een andere server dan de MyWorkDrive Server (MWD) bevinden, worden bereikt via DFS, of gebruikers worden geverifieerd met ADFS/SAML, om gebruikerstokens correct door te geven aan back-end bestandsshares, is het vereist dat de MyWorkDrive-server wordt vertrouwd door alle bestandsservers en DFS-servers voor delegatie.
Inschakelen via MyWorkDrive
Nieuw! Vanaf MyWorkDrive server 6.3 controleren ingebouwde scripts of delegeren is ingeschakeld en bieden ze aan om delegeren rechtstreeks vanuit MyWorkDrive voor u in te stellen.
Deze audit en het aanbod om te repareren is beschikbaar op zowel het tabblad 'Shares' als in het nieuwe Gezondheidsdashboard (ook een nieuwe functie van 6.3)
Op de lijst met shares ziet u mogelijk een waarschuwingspictogram dat delegatie vereist is, maar dat dit niet correct is ingesteld voor een bepaald aandeel of bepaalde aandelen.
Als u klikt om de share te bewerken, wordt zowel een delegatiewaarschuwing weergegeven als een knop die u vraagt Delegatie toe te voegen.
Als u op de knop "Delegatie toevoegen" klikt, wordt een bericht weergegeven over accountvereisten. U moet zijn aangemeld bij MyWorkDrive als een domeinbeheerder om de automatische delegatiefunctie te gebruiken. Als het account waarmee u MyWorkDrive beheert geen domeinbeheerder is, kunt u doorgaan met het inschakelen van delegeren met een van de onderstaande stappen.
De ingebouwde scripts die controleren of delegeren is ingeschakeld en aanbieden om delegeren rechtstreeks voor u in te stellen in MyWorkDrive, verschijnen ook in de nieuwe Gezondheidsdashboard met hetzelfde aanbod om de delegatiefunctie in te stellen.
Houd er rekening mee dat de geautomatiseerde methode mogelijk niet voor alle omgevingen werkt, met name voor omgevingen die een specifieke vorm van delegatie vereisen, zoals KCD. Als de geautomatiseerde methode niet voor u werkt, bekijk dan de aanvullende opties hieronder voor de meest geschikte methode voor uw omgeving.
Active Directory
Active Directory-gebruikers en computers
De meest gebruikelijke methode voor het configureren van delegatie is via de eigenschappen van de MyWorkDrive-server in Active Directory-gebruikers en computers. Configureer Active Directory-delegatie op het MyWorkDrive Server-computerobject om bestandsservers en DFS-servers in uw organisatie toe te voegen.
– Van een domeincontroller – Servermanager – Tools – Active Directory-gebruikers en computers – Computers – {selecteer computer waarop MWD is geïnstalleerd} – Eigenschappen – Delegatie – Deze computer alleen vertrouwen voor delegatie aan gespecificeerde services – Gebruik een willekeurig authenticatieprotocol – Toevoegen – Gebruikers of Computers – {selecteer computer(s) die de vereiste netwerkshares en computer(s) bevatten waarop DFS-rol is geïnstalleerd} – OK – Beschikbare services – selecteer cifs – OK
We sterk raden je aan NIET KIEZEN de optie die zegt: "Vertrouw deze computer voor overdracht aan servers (alleen Kerberos)." We sterk pleit ervoor dat u een Least Privileged Access-aanpak kiest door de servers en services te specificeren zoals hierboven beschreven. U kunt meer lezen over het beveiligen van uw active directory en delegatierisico's op Petri.com en ADSecurity.org
Voorbeeld van configuratie om MWD toestemming te geven om delegatie via File-Server1 en DFS-Server1 te vertrouwen: – MWD geïnstalleerd op computer MYWORKDRIVE-SERVER1 – Network File Share Server: FILE-SERVER1 – DFS Server: DFS-SERVER1
Met Powershell
Het is ook mogelijk om beperkte delegatie toe te wijzen aan CIFS via Powershell, maar het gebruik van de GUI-methode via ADUC wordt aanbevolen.
Om dit via Powershell te doen, moet u een lijst met de service-principalnamen (SPN's) van de FILESERVER opgeven in de MyWorkDrive Server(s)-account(s).
In het onderstaande voorbeeld vervangt u “FILESERVER” door de netbios-naam van uw bestandsserver en “MWDSERVER” door de netbios-naam van uw MyWorkDrive-server.
Om de lijst met SPN's te verkrijgen, kunt u de Get-ADComputer-cmdlet gebruiken en de eigenschap servicePrincipalName van de FILESERVER weergeven
Get-ADComputer FILESERVER -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName |format-list
u krijgt een lijst met vermeldingen zoals
host/FILESERVER
host/FILESERVER.domein.tld
Vervolgens moet u de cmdlet Set-ADComputer gebruiken waarbij de parameter msDS-AllowedToDelegate de waarden voor de sectie msDS-AllowedToDelegateTo vervangt door de SPN's van de FILESERVER
Get-ADComputer -Identity MWDSERVER | Set-ADAccountControl -TrustedToAuthForDelegation $true
Set-ADComputer -Identity MWDSERVER -Add @{'msDS-AllowedToDelegateTo'=@('cifs/FILESERVER','cifs/FILESERVER.domain.tld')}
Als u meer dan één bestandsserver heeft, kunt u doorgaan met het toevoegen van spns voor alle bestandsservers met dezelfde sytnax.
Als u meer dan één MyWorkDrive-server hebt, moet u de opdrachtenset voor elke MyWorkDrive-server uitvoeren.
Testen
Om te testen welke delegatie bestaat met Powershell, geeft deze opdracht u een lijst van de bestandsservers die uw MyWorkDrive-server vertrouwen voor delegatie.
Get-ADComputer MWDSERVER -Eigenschappen msDS-AllowedToDelegateTo,Displayname | selecteer Weergavenaam -ExpandProperty msDS-AllowedToDelegateTo | format-lijst
* Houd er rekening mee dat het minimaal 15 minuten duurt voordat Active Directory deze wijzigingen op de database heeft toegepast en gerepliceerd. Wacht minimaal 15 minuten voordat u begint met het testen van de toegang.
Beperkte Kerberos-delegatie
Voor sommige omgevingen is mogelijk de alternatieve configuratiemethode Kerberos Constrained Delegation (KCD) vereist.
Voor klanten met meerdere domeinen of degenen die hun Active Directory hosten in Azure AD Domain Services (dit is niet hetzelfde als Azure AD), moet overdracht worden ingeschakeld met behulp van beperkte overdracht op basis van bronnen in powershell. Sommige klanten in omgevingen met een hoge beveiliging of bij het gebruik van apparaten voor bestandsservers hebben mogelijk ook beperkte overdracht op basis van bronnen nodig.
Powershell-configuratiestappen voor Server 2012-domeinen of hoger vindt u in het Microsoft-artikel over het inschakelen van Kerberos-beperkte delegatie (KCD) op een beheerd domein en Computerdelegatie configureren met powershell.
Een voorbeeld van een MyWorkDrive Server-opdracht voor een bestandsserver en MyWorkDrive-server is als volgt:
Eén domein:
Set-ADComputer MyWorkDriveServer -PrincipalsAllowedToDelegateToAccount (Get-ADComputer FileServer)
Meerdere domeinen waar MyWorkDrive Server, gebruikers of bronnen zich in verschillende domeinen bevinden:
Vanaf de Windows-server die de feitelijke bestandsshares host die de MyWorkDrive-server vertrouwen, voert u een van de volgende powershell-opdrachten uit: waarbij $MyWorkDriveServer de naam is van de MyWorkDrive-server en $FileServer de naam is van de bestandsserver die uw domein invoert waar de MyWorkDrive-server bevindt zich in uw zoekopdracht in de zoekbasis of met behulp van de opgegeven domeincontroller waar de MyWorkDrive-server lid van is:
Opgegeven domeincontroller:
$MyWorkDriveServer= Get-ADComputer -Identity MYWORKDRIVE-SERVER -server mwf-dc.mwf.local
$FileServer= Get-ADComputer -Identiteit "FILE-SERVER" -server mwf-dc.mwf.local
$FileServer2= GetADComputer – Identificeer “FILE-SERVER2” – server mwf2.dc.mwf2.local
Set-ADComputer ($FileServer), ($FileServer2) -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer
Zoekbasis:
$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 Storage-gebruikersaccount
Om delegeren mogelijk te maken, moeten we de powershell-opdracht hieronder gebruiken om het Storage User-account in te stellen om de MyWorkDrive-servercomputer te vertrouwen als gemachtigd om te delegeren naar het gebruik van KCD. We moeten ook het MyWorkDrive-servercomputeraccount en de gebruikersaccount(s) voor de Azure-bestandsshares verplaatsen van de standaard OU's naar een aangepaste OU. Details zijn beschikbaar in dit Microsoft-artikel
OU
De accounts voor de MyWorkDrive-servercomputer en de Azure File Shares-gebruiker(s) moeten zich in een aangepaste organisatie-eenheid bevinden waar u gemachtigd bent om op bronnen gebaseerde KCD te configureren. U kunt geen op bronnen gebaseerde KCD configureren voor een computeraccount in de ingebouwde AAD DC Computers-container.
Powersell-instellingen
$ImpersonatingAccount = Get-ADComputer -Identiteit
Set-ADUser -Principals mogen delegeren aan account $Impersonerende account
Houd er rekening mee dat u voor de StorageUserAccount mogelijk de SAM-accountnaam moet gebruiken, niet de naam/algemene naam. Zoek de SAM-accountnaam als de pre-windows 2000-naam op het accounttabblad van de items in ADUC of met Get-ADUser in Powershell
Voorbeeld Powershell
MWD01 – naam van de MyWorkDrive-server
SA_81e0bcb563 – SAMAccountName van de Azure-bestandsshare
$ImpersonatingAccount = Get-ADComputer-Identity MWD01
Set-ADUser SA_81e0bcb563 -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
Testen
Voer de volgende powershell-opdracht uit om de delegatie te controleren:
Get-ADComputer $MyWorkDriveServer -Eigenschappen * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity
Of
Beginnend met MyWorkDrive Server 5.4 of hoger, voer de tests uit in het MyWorkDrive Server-beheerpaneel op elke share met behulp van onze ingebouwde testtool.
Speciale gevallen – DFS en AzureFiles
DFS
Wanneer u DFS gebruikt met SSO en MyWorkDrive, moet u Delegatie instellen voor de MyWorkDrive-server voor zowel de DFS-computers ALS de bestandsshareservers.
IE, als je de volgende servers hebt:
DFS1 DFS2
Geconfigureerd om bestanden te delen van de volgende bestandsservers (Windows of AD Joined Storage Devices) FileShareSanJose FileShareHouston FileShareNewYork
Vervolgens moeten alle vijf AD-leden worden weergegeven als goedgekeurd om te delegeren via CIFS op het tabblad AD-delegatie van de MyWorkDrive-server
Azure-bestanden
Wanneer je onze . succesvol hebt afgerond installatiehandleiding voor het gebruik van Azure Files met MyWorkDrive, wordt uw Azure Files Storage-account een domein lid. Dat domeinlid moet worden toegevoegd aan Delegation voor de MyWorkDrive-server zodat SSO die schijf correct kan presenteren als een share aan gebruikers.
Probleemoplossen
Als uw shares blanco worden weergegeven wanneer gebruikers inloggen via SSO, is delegatie waarschijnlijk niet correct ingesteld. Als u denkt dat u Delegatie via KCD of Active Directory correct hebt ingesteld, kunt u Powershell gebruiken om te testen of de bestandsshareserver/-appliance de delegatie correct accepteert. Dit zal u vertellen of de ingelogde gebruiker toegang heeft tot bestanden en mappen op de gedelegeerde bestandsshare.
U kunt een heel eenvoudig Powershell-script gebruiken om te testen of delegatie correct is ingesteld, met behulp van een techniek die bekend staat als de "Double Hop". Aanvullende informatie over deze test is te vinden op: https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/ Om deze test uit te voeren, heb je 3 machines in je active directory nodig
- Client – dit kan elke machine zijn die lid is van een domein; zoals een Windows 10-werkstation. U voert de Powershell-opdracht uit vanaf de machine.
- MyWorkDrive Server – de server die toegang moet hebben tot de share via delegatie
- Bestandsserver – de server die is ingesteld voor delegatie op de MyWorkDrive-server.
U moet ook het sharepad weten van een share op de bestandsserver die bestanden bevat en waartoe de ingelogde gebruiker toegang heeft. Het powershell-commando is Invoke-Command -ComputerName $MyWorkDriveServerName -ScriptBlock {Get-ChildItem -Path \\$FileServer\ShareName} U vervangt $MyWorkDriveServerName door de netwerknaam van uw MyWorkDrive-server. U vervangt $FileServer\ShareName door de bestandsserver en de share die u wilt testen. De share moet bestanden bevatten waarvan u verwacht dat de gebruiker er toegang toe heeft. En voer de opdracht uit vanaf het Client-werkstation Voorbeeld In ons voorbeeld testen we delegatie naar een Linux Samba Share van twee verschillende MyWorkDrive-servers. Op de ene MyWorkDrive-server is delegatie ingesteld, op de andere niet. We testen vanaf een Windows 10-client op het domein. Delegatie niet ingesteld In deze test zullen we delegatie testen op een server waar we opzettelijk geen delegatie hebben ingesteld en een fout verwachten.
- MyWorkDrive-server: mwf-scott6
- Bestandsserver: ubuntu-samba
- Delen: iedereen
Voer Powershell uit op het Windows 10-domeinlid en voer de volgende opdracht uit: Invoke-Command -ComputerName mwf-scott6 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone} De resultaten die we krijgen zijn: Een fout dat het bestandspad niet bestaat. Delegeren werkte niet en onze gebruiker had geen toegang tot de share. In dit scenario wordt de share leeg weergegeven wanneer de gebruiker zich aanmeldt bij MyWorkDrive via SSO. Dit is het verwachte resultaat omdat we geen delegatie hebben ingesteld. Het kan er ook op wijzen dat uw bestandsserver/apparaat geen delegatie accepteert, indien correct ingesteld. Delegatie instellen In deze test zullen we delegatie testen op een server waar delegatie correct is ingesteld
- MyWorkDrive-server: mwf-scott5
- Bestandsserver: ubuntu-samba
- Delen: iedereen
Voer Powershell uit op het Windows 10-domeinlid en voer de volgende opdracht uit: Invoke-Command -ComputerName mwf-scott5 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone} De resultaten die we krijgen zijn: Een lijst met bestanden en mappen in de directory. Delegeren werkte wel en onze gebruiker had toegang tot de share.
Windows-update november 2021
Patches die door Microsoft zijn uitgebracht tijdens de patchdinsdag van november 2021 op 9 november, veroorzaken lege shares bij het inloggen met SSO op dezelfde manier als het niet correct inschakelen van delegatie. Het probleem werd eind november opgelost met patches en uiteindelijk opgelost in de roll-ups van december en januari.
Vanaf medio 2022 zouden zich geen verdere gevallen hiervan moeten voordoen, aangezien die updates niet langer relevant zijn.
We nemen deze informatie op voor archiveringsdoeleinden
Als aanmeldingen plotseling leeg lijken op een bestaande MyWorkDrive-installatie die voorheen goed werkte, moet u de gebrekkige patch herstellen, zie dit artikel voor details.
Als u SSO voor het eerst instelt op uw MyWorkDrive-server, zie het artikel voor meer informatie over het toepassen van de fix naar uw domeincontrollers, naast het configureren van delegatie zoals hieronder beschreven.
De fix voor de patch geleverd via Windows Update moet handmatig worden toegepast. Zonder de fix voor de Windows Update-patch toe te voegen, zullen aanmeldingen resulteren in lege shares.