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.

Enable via MyWorkDrive

New! As of MyWorkDrive server 6.3, built in scripts will audit to see if 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)

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

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 enviornments, particuarly 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 enviornment.

Active Directory

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).” 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

With Powershell

It is also possible to assign delegation contstrained to CIFS via Powershell, however using the GUI method through ADUC is recommended.

To do it through Powershell, you must specify a list of the FILESERVER’s service principal names (SPNs) in the MyWorkDrive Server(s) account(s).

In the example below you will replace “FILESERVER” with the netbios name of your file server and “MWDSERVER” with the netbios name of your MyWorkDrive server.

To obtain the list of SPNs, you can use the Get-ADComputer cmdlet and display the servicePrincipalName property of the FILESERVER

Get-ADComputer FILESERVER -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName |format-list

you will get a list which includes entries like
host/FILESERVER
host/FILESERVER.domain.tld

Then you must use Set-ADComputer cmdlet with the msDS-AllowedToDelegate parameter replacing the values for the msDS-AllowedToDelegateTo section with the SPNs of the FILESERVER

Get-ADComputer -Identity MWDSERVER | Set-ADAccountControl -TrustedToAuthForDelegation $true
Set-ADComputer -Identity MWDSERVER -Add @{‘msDS-AllowedToDelegateTo’=@(‘cifs/FILESERVER’,’cifs/FILESERVER.domain.tld’)}

If you have more than one file server, you can continue adding spns for all the file servers using the same sytnax.
If you have more than one MyWorkDrive server, you will need to run the command set for each MyWorkDrive Server.

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.

Get-ADComputer MWDSERVER -Properties msDS-AllowedToDelegateTo,Displayname | select Displayname -ExpandProperty msDS-AllowedToDelegateTo | format-list

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

 

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

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 Settings
$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, run the tests in the MyWorkDrive Server Admin panel on each share using our built in test tool.

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