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

The instructions in this article are only applicable to MyWorkDrive installations using Active Directory for user identity and SMB File shares. Delegation is not required when using Entra ID as the user 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:

Specified Domain Controller:

$MyWorkDriveServer= Get-ADComputer -Identity MYWORKDRIVE-SERVER -server mwf-dc.mwf.local

$FileServer= Get-ADComputer -Identity “FILE-SERVER” -server mwf-dc.mwf.local

$FileServer2= GetADComputer – Identify “FILE-SERVER2” – server mwf2.dc.mwf2.local

Set-ADComputer ($FileServer),($FileServer2) -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer

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

 

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 sample PowerShell script, 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.

Entra ID Domain Services Storage User Account

To enable delegation with Entra ID 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.

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