Hoe kunnen we u vandaag helpen?

Delegatie instellen voor ADFS/SAML-, bestands- en DFS-servers in Active Directory

U bent hier:
< Terug

 

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.

Soorten delegatie

Er zijn twee soorten delegatie die u kunt gebruiken met MyWorkDrive.

  • Beperkte delegatie / Kerberos beperkte delegatie of KCD
  • Op bronnen gebaseerde beperkte Kerberos-delegatie (RBKCD)

Constrained Delegation of Kerberos Constrained Delegation (KCD) kan worden ingesteld via de ADUC UI of via Powershell. Het is het meest voorkomende type, dat wordt gebruikt in gevallen waarin u een enkel domein heeft zonder externe vertrouwensrelaties.
Met beperkte delegatie beperkt u de toegang tot een specifieke service (in het geval van MyWorkDrive, CIFS)
Met Kerberos Constrained Delegation (KCD) beperk je het verificatietype tot Kerberos en de service tot CIFS.

Resource Based Kerberos Constrained Delegation kan alleen worden ingesteld via Powershell. Met RBKCD specificeert u bovendien welke servers (resources) toegangsverzoeken zullen toestaan.
Het wordt meestal gebruikt wanneer een externe vertrouwensrelatie in gebruik is (dwz er zijn bronnen op twee verschillende domeinen waartoe u toegang hebt, zoals een MyWorkDrive-server en gebruikers op Domein1, met bestandsshares op Domein2). Met een trust moeten resources specifiek worden verteld van wie ze autorisatieverzoeken kunnen accepteren. Ze accepteren geen autorisatieverzoeken voor meerdere domeinen, tenzij ze specifiek zijn geautoriseerd. Meer informatie over vertrouwensconfiguratie in Dit artikel.

In deze artikelen vindt u meer informatie over de soorten verschillende delegaties
Overzicht beperkte Kerberos-delegatie
De tweede hop maken in PowerShell Remoting, die een goed overzicht heeft van de use cases voor KCD en RBKCD
Kerberos-delegatie, Een goede bespreking van de KCD/RBKCD-implementatie

Deze artikelen vermelden andere vormen van authenticatie, zoals credSSP en JEA, die niet worden gebruikt met MyWorkDrive, en onbeperkte delegatie, die we niet aanbevelen vanwege de beveiligingsimplicaties.

Inschakelen via MyWorkDrive

Vanaf MyWorkDrive-server 6.3 controleren ingebouwde scripts of beperkte delegatie is ingeschakeld en bieden ze aan om delegatie rechtstreeks voor u in te stellen vanuit MyWorkDrive.

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)
Deze functie werkt met beperkte delegatie, meestal ingesteld via ADUC-gebaseerde GUI-instelling van delegatie. Het detecteert KCD/RBKCD niet en de waarschuwingen kunnen in die gevallen veilig worden genegeerd.

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

Beperkte delegatie

Beperkte delegatie instellen via ADUC UI 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 – Serverbeheer – Tools – Active Directory: gebruikers en computers – Computers – {selecteer computer waarop MWD is geïnstalleerd} – Eigenschappen – Delegeren – Vertrouw deze computer alleen voor delegeren naar gespecificeerde services – Gebruik elk authenticatieprotocol – Toevoegen – Gebruikers of Computers – {selecteer computer(s) met de vereiste netwerkshares en computer(s) waarop de 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 delegatie naar alle servers (alleen Kerberos)." (onbeperkte delegatie) Wij sterk pleit ervoor dat u een Least Privileged Access-benadering volgt door de servers en services te specificeren zoals hierboven beschreven (Constrained Delegation). U kunt meer lezen over het beveiligen van uw active directory en de risico's van delegeren op Petri.com en ADSecurity.org

Voorbeeld van configuratie om MWD in staat te stellen delegatie te vertrouwen via File-Server1 en DFS-Server1: – 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.

Dit scriptvoorbeeld maakt een array van alle bestandsservers en maakt delegatie naar die specifieke bestandsservers op het CIFS-protocol naar de MyWorkDrive-server(s) mogelijk

# Importeer de ActiveDirectory-module
Import-module ActiveDirectory

# Maak een array en wijs deze toe aan een variabele. Voeg in de @-component de namen toe van uw bestandsservers of
#DFS-hostservers.
$TargetComputers = @(“FileShare1”, “DFSshare1”)

# Doorloop elk element van de array en configureer de delegatie
Voor elke ($Computer in $TargetComputers) {

# Maak verbinding met de MyWorkDrive-server – vervang de uitdrukking "MWDServer" door de netbios-naam van uw
#MYWorkDrive-server. Als u er meer dan 1 heeft, voert u dit hele script meer dan eens uit.
Get-ADComputer-identiteit MWDServer

# Voeg de CIFS SPN van de huidige computer toe aan de lijst met services waarnaar FileServer kan delegeren
Set-ADComputer -Identity MWDServer -Add @{'msDS-AllowedToDelegateTo'= "cifs/$Computer"}
}

Testen

Om te testen welke delegatie bestaat met behulp van Powershell, geeft deze opdracht u een lijst met de bestandsservers die uw MyWorkDrive-server vertrouwen voor delegatie. Vervang in het onderstaande script "MWDServer" door de netbios-naam van uw MyWorkDrive-server.

Get-ADComputer MWDSERVER -Eigenschappen msDS-AllowedToDelegateTo,Displayname | selecteer Weergavenaam -ExpandProperty msDS-AllowedToDelegateTo | format-lijst

*Let op: het duurt minimaal 15 minuten voordat Kerberos-tickets zijn gerecycled en mogelijk langer voordat Active Directory de wijzigingen heeft doorgevoerd. Wacht minimaal 15 minuten voordat u begint met het testen van de toegang.

Mogelijk kunt u de argumenten "purge" en "–li 0x3e7" gebruiken met de klijst commando op de bestandsservers en MyWorkDrive-servers om het recycle-gedeelte te versnellen, maar we hebben gemerkt dat het niet bijzonder effectief is.

Op bronnen gebaseerde beperkte Kerberos-delegatie

Voor sommige omgevingen is mogelijk de alternatieve configuratiemethode Resource Based Kerberos Constrained Delegation (RBKCD) vereist.

Voor klanten met meerdere domeinen (domein vertrouwt) of degenen die hun Active Directory hosten in Azure AD Domain Services (dit is niet hetzelfde als Azure AD), moet delegeren worden ingeschakeld met behulp van beperkte delegatie op basis van resources in powershell. RBKCD is vereist voor vertrouwde domeinen omdat het de enige veilige delegatiemethode is die dubbele hop-authenticatie ondersteunt. Hierin staan meer details Microsoft-artikel. Sommige klanten in sterk beveiligde omgevingen of bij het gebruik van file serving-appliances kunnen ook beperkte delegatie op basis van resources vereisen.

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 eigenlijke bestandsshares host, die de MyWorkDrive-server zal 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 De MyWorkDrive-server bevindt zich in uw zoekopdracht in de zoekbasis of gebruikt de opgegeven domeincontroller waar de MyWorkDrive-server lid van is:

 

Meerdere/vertrouwde domeincontrollers en meerdere MyWorkDrive-servers:

Het is belangrijk op te merken dat het uitvoeren van de opdracht Set-ADComputer in powershell dat wel doet wissen eventuele bestaande delegatievermeldingen en vervangen ze met uw nieuwe inzendingen. Als u al setup-delegatie heeft voor bestaande services, kan dit ongewenste gevolgen hebben. Met behulp van de aanbevolen methode zoekt u eerst bestaande delegatie-instellingen op en neemt u die servers op in het delegatie-item, waarbij u bestaande delegatie-instellingen behoudt terwijl u nieuwe toevoegt voor uw MyWorkDrive-server.

Je kunt een zipbestand van dit PS1-script downloaden hier.

Hier is de inhoud van het script:

1TP5BELANGRIJKE OPMERKING: Dit script overschrijft alle bestaande Resource Based Delegation-instellingen op de doelcomputers.
#Voer de volgende opdracht uit om bestaande delegatie-instellingen te bekijken en voeg ze toe aan de $MWDServerlijst:
Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount

#He lijst kan SID's gebruiken als deze afkomstig is van een vertrouwd domein. Als u een SID krijgt, gebruikt u de volgende opdracht om de SID te vertalen
1TP5Dhet vertrouwde domein:
Get-ADComputer –Filter * | Where-Object {$_.SID –zoals “*1111”} | Select-Object – Eigenschapsnaam, SID
1TP5Vervang "1111" door de laatste 4 cijfers van de SID

# Importeer de ActiveDirectory-module
Import-module ActiveDirectory

# Maak een array en wijs deze toe aan een variabele
#TargetComputers is voor de lijst met bestandsservers en DFS-shares in de omgeving.
1TP5Vervang "FileShare1", "DFSSHare1" door de netbios-namen van uw bestandsshares en DFS-hosts.
#Voeg er zoveel toe als nodig is.
#Domain is uw domeinnaam in URL-formaat, dwz domain.local
$TargetComputers = @(“FileShare1”, “DFSShare1”)
$Domain = "domein.tld"

$huidige delegatie
$MWDServer1 = (Get-ADComputer-identiteit MWDServer1)
$MWDServer2 = (Get-ADComputer-identiteit MWDServer2)

# Doorloop elke bestands-/DFS-serverconfiguratiedelegatie voor de MyWorkDrive-server
Voor elke ($Computer in $TargetComputers) {

# Voeg de bron van de huidige computer toe aan de lijst met services waarnaar FileServer kan delegeren
# de “-server domain.tld”'s kunnen worden verwijderd als alle servers/computers zich binnen hetzelfde domein bevinden; geef anders het domein op.
Set-ADComputer -Identity $Computer -server $domain -PrincipalsAllowedToDelegateToAccount $MWDServer1, $MWDServer2

# Controleer of de waarde van het kenmerk de MyWorkDrive-server omvat. Als het afkomstig is van een vertrouwd domein, wordt het weergegeven als een SID.
Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount
} 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

Testen

Om te testen of uw wijzigingen zijn gelukt, voert u de opdracht uit om de delegatie-instellingen uit stap 1 van dit proces te bekijken.
#Get-ADComputer -Identiteit $Computer -server $domain -Eigenschappen PrincipalsAllowedToDelegateToAccount

U zou nu de reeds bestaande vermeldingen moeten zien, samen met de nieuwe bronnen die u hebt toegevoegd.

*Zoals eerder in dit artikel opgemerkt, duurt het ten minste 15 minuten voordat Kerberos-tickets zijn gerecycled en mogelijk langer voordat Active Directory de wijzigingen heeft doorgevoerd. Wacht ten minste 15 minuten voordat u begint met het testen van de toegang.

Mogelijk kunt u de argumenten "purge" en "–li 0x3e7" gebruiken met de klijst commando op de bestandsservers en MyWorkDrive-servers om het recycle-gedeelte te versnellen, maar we hebben gemerkt dat het niet bijzonder effectief is.

 

Azure AD Domain Services Storage-gebruikersaccount

Om delegeren met Azure AD Domain Services en een Storage User Account mogelijk te maken, moeten we de powershell-opdracht hieronder gebruiken om het Storage User-account zo in te stellen dat de MyWorkDrive-servercomputer wordt vertrouwd 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 standaard OE's naar een aangepaste OU. Details zijn beschikbaar in dit Microsoft-artikel. Delegatie werkt niet als de accounts in Active Directory niet uit de standaard OU's worden verplaatst.

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-opdrachten
$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

Vanaf MyWorkDrive Server 5.4 of hoger kunt u ervoor kiezen om de tests uit te voeren in het MyWorkDrive Server-beheerderspaneel op elke share met behulp van onze ingebouwde Testtool delen, in plaats van u als gebruiker aan te melden bij een client.

Speciale gevallen – DFS en AzureFiles

DFS

Wanneer u DFS met SSO en MyWorkDrive gebruikt, moet u Delegatie instellen voor de MyWorkDrive-server voor zowel de DFS-computers/hosts als de servers voor het delen van bestanden.

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 Delegatie voor de MyWorkDrive-server, zodat SSO die schijf op de juiste manier als een share aan gebruikers kan presenteren.

Probleemoplossen

Als uw shares leeg 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 delegeren 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". Meer 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 computer 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 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 via SSO aanmeldt bij MyWorkDrive. Dit is het verwachte resultaat, aangezien we geen delegatie hebben ingesteld. Het kan ook aangeven 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 die via Windows Update wordt geleverd, moet handmatig worden toegepast. Zonder de fix voor de Windows Update-patch toe te voegen, resulteren aanmeldingen in lege shares.