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 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 and DFS Servers for delegation.

Setup via Active Directory

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

Setup KCD

For customers 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:

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

Testing

To check delegation run the following powershell command:

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

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.