How can we help you today?
Delegation Setup for ADFS/SAML, File and DFS Servers in Active Directory
Overview
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 File Servers and DFS Servers for delegation.
Types of Delegation
There are two types of Delegation you may choose to use with MyWorkDrive.
- Constrained Delegation / Kerberos Constrained Delegation or KCD
- Resource Based Kerberos Constrained Delegation (RBKCD)
Constrained Delegation or Kerberos Constrained Delegation (KCD) can be set through the ADUC UI or via Powershell. It is the most common type, used in cases where you have a single domain without external trusts.
With Constrained Delegation, you are limiting access to a specific service (in the case of MyWorkDrive, CIFS)
With Kerberos Constrained Delegation (KCD), you are limiting the authentication type to Kerberos and the service to CIFS.
Resource Based Kerberos Constrained Delegation can only be set via Powershell. With RBKCD, you are additionally specifying what servers (resources) will permit access requests.
It is most commonly used when an external trust is in use (ie there are resources on two different domains you are accessing, such as a MyWorkDrive server and users on Domain1, with file shares on Domain2.). With a Trust, resources have to be specifically told where to accept authorization requests from, they do not accept cross domain authorization requests unless specifically authorized. Learn more about Trust configuration in this article.
You can learn more about the types of different delegation in these articles
Kerberos Constrained Delegation Overview
Making the second hop in PowerShell Remoting, which has a good overview of the use cases for KCD and RBKCD
Kerberos Delegation, A good discussion of KCD/RBKCD implementation
These articles mention other forms of authentication, such as credSSP and JEA, which are not used with MyWorkDrive, and Unconstrained Delegation, which we do not recommend due to the security implications.
Enable via MyWorkDrive
As of MyWorkDrive server 6.3, built in scripts will audit to see if Constrained 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)
This feature works with Constrained Delegation, most frequently set via ADUC based GUI setting of delegation. It does not detect KCD/RBKCD and the warnings can safely be ignored in those cases.
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 Delegation.
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 environments, particularly 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 environment.
Constrained Delegation
Setting Constrained Delegation via ADUC UI Active Directory Users and Computers
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 and DFS 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).” (unconstrained delegation) We strongly advocate you take a Least Privileged Access approach by specifying the servers and services as described above (Constrained Delegation). You can read more about securing your active directory and delegation risks on Petri.com and ADSecurity.org
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
With Powershell
It is also possible to assign delegation constrained to CIFS via Powershell, however using the GUI method through ADUC is recommended.
This script example will create an array of all the FileServers and enable delegation to those specific file servers on the CIFS protocol to the MyWorkDrive server(s)
—
# Import the ActiveDirectory module
Import-Module ActiveDirectory
# Create an array and assign it to a variable. In the @ component, add the names of your file servers or
#DFS host servers.
$TargetComputers = @(“FileShare1”, “DFSshare1”)
# Loop through each element of the array and configure delegation
ForEach ($Computer in $TargetComputers) {
# Connect to the MyWorkDrive Server – replace the phrase “MWDServer” with the netbios name of your
#MYWorkDrive server. If you have more than 1, you will run this entire script more than once.
Get-ADComputer -Identity MWDServer
# Add the CIFS SPN of the current computer to the list of services that FileServer can delegate to
Set-ADComputer -Identity MWDServer -Add @{‘msDS-AllowedToDelegateTo’= “cifs/$Computer”}
}
—
Testing
To test what delegation exists using Powershell, this command will give you a list of the file servers which trust your MyWorkDrive server for delegation. In the script below, replace “MWDServer” with the netbios name of your MyWorkDrive server.
—
Get-ADComputer MWDSERVER -Properties msDS-AllowedToDelegateTo,Displayname | select Displayname -ExpandProperty msDS-AllowedToDelegateTo | format-list
—
*Note it takes at least 15 minutes for Kerberos tickets to recycle and potentially longer for Active Directory to propagate the changes – Wait at least 15 minutes before beginning testing access.
You may be able to use the “purge” and “–li 0x3e7” arguments with the klist commandon the file servers and MyWorkDrive servers to expedite the recycle portion, but we have not found it to be particularly effective.
Resource Based Kerberos Constrained Delegation
Some environments may require the alternate configuration method, Resource Based Kerberos Constrained Delegation (RBKCD) .
For customers with multiple domains (domain trusts) 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. RBKCD is required for trusted domains as it is the only secure delegation method that supports double hop authentication. More details are available in this Microsoft Article. Some customers in high security environments or when using file serving appliances 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 MyWorkDriveServer -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, which will trust the MyWorkDrive server, run either set of the following powershell commands: where $MyWorkDriveServer is the name of the MyWorkDrive server and $FileServer is the name of the file server inputting your Domain where the MyWorkDrive server is located into your query in the searchbase or using the specified domain controller where the MyWorkDrive Server is a member:
Multiple/Trusted Domain Controllers and Multiple MyWorkDrive Servers:
It is important to note that running Set-ADComputer command in powershell will erase any existing delegation entries and replace them with your new entries. If you already have setup delegation for existing services, this can have undesirable consequences. Using the recommended method, you will first lookup existing delegation settings and include those servers into the delegation entry, preserving existing delegation settings while adding new ones for your MyWorkDrive server.
You can download a zip file of this PS1 script here.
Here is the script contents:
—
#IMPORTANT NOTE: This script will overwrite any existing Resource Based Delegation settings on the Target Computers.
#Please run the following command to view any existing delegation settings and append them to the $MWDServer List:
Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount
#The list may use SID’s if it is from a trusted domain. If you are given an SID, use the following command to translate the SID from
#the trusted domain:
Get-ADComputer –Filter * | Where-Object {$_.SID –like “*1111”} | Select-Object –Property Name, SID
#replace “1111” with the last 4 digits of the SID
# Import the ActiveDirectory module
Import-Module ActiveDirectory
# Create an array and assign it to a variable
#TargetComputers is for the list of File Servers and DFS Shares in the environment.
#replace “FileShare1”, “DFSSHare1” with the netbios names of your file shares and DFS Hosts.
#Add as many as necessary.
#Domain is your domain name in URL format, ie domain.local
$TargetComputers = @(“FileShare1”, “DFSShare1”)
$Domain = “domain.tld”
$CurrentDelegation
$MWDServer1 = (Get-ADComputer -Identity MWDServer1)
$MWDServer2 = (Get-ADComputer -Identity MWDServer2)
# Loop through each File/DFS Server configure delegation for the MyWorkDrive Server
ForEach ($Computer in $TargetComputers) {
# Add the resource of the current computer to the list of services that FileServer can delegate to
# the “-server domain.tld”‘s can be removed if all servers/computers are contained within the same domain; otherwise, specify the domain.
Set-ADComputer -Identity $Computer -server $domain -PrincipalsAllowedToDelegateToAccount $MWDServer1, $MWDServer2
# Verify the value of the attribute includes the MyWorkDrive Server. If it is from a trusted domain, it will show as an SID.
Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount
} Searchbase:
$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
—
Testing
To test that your changes were successful, run the command to view delegation settings from step 1 of this process.
#Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount
You should now see the pre-existing entries along with the new resources you added.
*As noted previously in this article, it takes at least 15 minutes for Kerberos tickets to recycle and potentially longer for Active Directory to propagate the changes – Wait at least 15 minutes before beginning testing access.
You may be able to use the “purge” and “–li 0x3e7” arguments with the klist commandon the file servers and MyWorkDrive servers to expedite the recycle portion, but we have not found it to be particularly effective.
Azure AD Domain Services Storage User Account
To enable delegation with Azure AD Domain Services and a Storage User Account, 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. Delegation will not work if the accounts in Active Directory are not moved out of the default OUs.
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 commands
$ImpersonatingAccount = Get-ADComputer -Identity <MyWorkDriveServerName>
Set-ADUser <StorageUserAccount> -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
Testing
To check delegation run the following powershell command:
Get-ADComputer $MyWorkDriveServer -Properties * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity
Or
Starting with MyWorkDrive Server 5.4 or higher, you may choose to run the tests in the MyWorkDrive Server Admin panel on each share using our built in Share test tool, instead of signing in to a client as a user.
Special Cases – DFS and AzureFiles
DFS
When you are using DFS with SSO and MyWorkDrive, you must setup Delegation for the MyWorkDrive server for both the DFS computers/hosts AND the file share servers.
IE, if you have the following servers
DFS1 DFS2
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.
Troubleshooting
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 https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/ 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. 
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
If Logins suddenly appear blank on an existing MyWorkDrive installation which previously worked fine, you need to remidate the flawed patch, see this article for details.
If you are setting up SSO for the first time on your MyWorkDrive server, please see the article for details about applying the fix to your domain controllers, in addition to configuring delegation as described below.
The fix for the patch supplied via Windows Update must be manually applied. Without adding the fix for the Windows Update patch, logins will result in blank shares.
