MyWorkDrive Support

How can we help you today?

Delegation Setup for ADFS/SAML, File and DFS Servers in Active Directory

You are here:
< Back

This article describes the Delegation Setup steps for ADFS/SAML to function properly with any back-end File and DFS Servers in Active Directory.

When file shares are located on a different server from the MyWorkDrive Server (MWD), will be reached through DFS, or users will be authenticated using ADFS/SAML, to properly pass user tokens to back end file shares it is required that the MyWorkDrive Server is trusted by any ADFS, File Servers and DFS Servers for delegation.

Active Directory

The most common method of configuring Delegation is through the properties of the MyWorkDrive server in Active Directory users and Computers. Configure Active Directory Delegation on the MyWorkDrive Server computer object to add any File Servers, DFS Servers and ADFS servers in your organization.

– From a Domain Controller – Server Manager – Tools – Active Directory Users and Computers – Computers – {select computer where MWD is installed} – Properties – Delegation – Trust this computer for delegation to specified services only – Use any authentication protocol – Add – Users or Computers – {select computer(s) that contains required network shares and computer(s) with DFS role installed} – OK – Available services – select cifs – OK

We strongly recommend you DO NOT SELECT the option which says “Trust this computer for delegation to any servers (Kerberos only).” We strongly advocate you take a Least Privileged Access approach by specifying the servers and services as described above.  You can read more about securing your active directory and delgation risks on and

Example of configuration to allow MWD to trust delegation through File-Server1 and DFS-Server1: –    MWD installed on computer MYWORKDRIVE-SERVER1 –    Network File Share Server: FILE-SERVER1 –    DFS Server: DFS-SERVER1

* Note it takes at least 15 minutes for active directory to apply these changes to it’s database and replicate – Wait at least 15 minutes before beginning testing access.

Kerberos Constrained Delegation

Some environments may require the alternate configuration method,  Kerberos Constrained Delegation (KCD) .

For customers with multiple domains or those who are hosting their Active Directory in Azure AD Domain Services (this is not the same as Azure AD), delegation must be enabled using resource based constrained delegation in powershell.   Some customers in high security environments may also require resource based constrained delegation.  Powershell Configuration Steps for Server 2012 domains or higher are located in Microsoft’s article on how to enable Kerberos constrained delegation (KCD) on a managed domain and How to configure computer delegation with powershell.    An example MyWorkDrive Server command for a File Server and MyWorkDrive server is as follows:

Single Domain:

Set-ADComputer MYWORKDRIVE-SERVER -PrincipalsAllowedToDelegateToAccount (Get-ADComputer FILESERVER)

Multiple Domains where MyWorkDrive Server, Users or Resources are in different domains:

From the Windows server that hosts the actual file shares that will trust the MyWorkDrive server run the following powershell command: where $myworkdriveserver is the name of the MyWorkDrive server and “File-Server” is the name of the file server inputting your Domain where the MyWorkDrive server is located into your query in the searchbase:

$myworkdriveserver= Get-ADComputer -Filter {Name -eq “MYWORKDRIVE-SERVER”} -SearchBase “DC=MWF,DC=local” -Server “mwf.local” Set-ADComputer FILE-SERVER -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Azure AD Domain Services Storage User Account

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:
$ImpersonatingAccount = Get-ADComputer -Identity <MyWorkDriveServerName>
Set-ADUser <StorageUserAccount> -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount



To check delegation run the following powershell command:

Get-ADComputer MYWORKDRIVE-SERVER -Properties * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity


Starting with MyWorkDrive Server 5.4 or higher, run the tests in the MyWorkDrive Server Admin panel on each share using our built in test tool.

Special Cases – DFS and AzureFiles


When you are using DFS with SSO and MyWorkDrive, you must setup Delegation for the MyWorkDrive server for both the DFS computers AND the file share servers.

IE, if you have the following servers


Configured to share files from the following file servers (Windows or AD Joined Storage Devices) FileShareSanJose FileShareHouston FileShareNewYork

Then all five AD members should appear as approved to delegate via CIFS on the AD Delegation tab of the MyWorkDrive Server


Azure Files

When you have successfully completed our setup guide to using Azure Files with MyWorkDrive, your Azure Files Storage Account will be a domain member.  That domain member needs to be added to Delegation for the MyWorkDrive server in order for SSO to properly present that drive as a share to users.


If your shares are showing up blank when users login via SSO, it is likely that Delegation is not setup correctly.  If you believe you have correctly setup Delegation via KCD or Active Directory, you may use Powershell to test if the file share server/appliance is correctly accepting delegation.  This will tell you if the logged in user can access files and folders on the delegated file share.

You can use a very simple Powershell script to test if Delegation is set correctly, using a technique knows as the “Double Hop”.  Additional information about this test can be found at To conduct this test, you will need 3 machines on your active directory

  • Client – this can be any domain joined machine; such as a windows 10 workstation.  You’ll run the Powershell command from the machine.
  • MyWorkDrive Server – the server which should be able to access the share via delegation
  • File Server – the server which is set for Delegation on the MyWorkDrive Server.

You’ll also need to know the share path of a share on the file server which has files in it, which the logged-in user can access. The powershell command is Invoke-Command -ComputerName $MyWorkDriveServerName -ScriptBlock {Get-ChildItem -Path \\$FileServer\ShareName } You’ll replace $MyWorkDriveServerName with the network name of your MyWorkDrive server You’ll replace $FileServer\ShareName with the file server and share you’re wanting to test.  The share should have files in it, which you expect the user to have access to. And run the command from the Client workstation Example In our example, we are testing delegation to a Linux Samba Share from two different MyWorkDrive Servers. One MyWorkDrive server has delegation set, the other does not. We are testing from a Windows 10 client on the domain. Delegation Not Setup In this test, we will test delegation on a server where we intentionally did not setup delegation and expect an error.

  • MyWorkDrive Server: mwf-scott6
  • File Server: ubuntu-samba
  • Share: everyone

Run Powershell on the Windows 10 domain member and execute the following command Invoke-Command -ComputerName mwf-scott6 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } The results we get are: An error that the file path does not exist. Delegation did not work and our user was not able to access the share. In this scenario, the share will show up blank when the user logs in to MyWorkDrive via SSO.  This is the expected outcome as we did not setup delegation.  It may also indicate that your File Server/Appliance is not accepting delegation, if setup correctly. Delegation Setup In this test, we will test delegation on a server where delegation is setup correctly

  • MyWorkDrive Server: mwf-scott5
  • File Server: ubuntu-samba
  • Share: everyone

Run Powershell on the Windows 10 domain member and execute the following command Invoke-Command -ComputerName mwf-scott5 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } The results we get are: A list of files and folders in the directory. Delegation did work, and our user was able to access the share.