This took some time to figure this out becasue I was a little impatient between tests. It seems that the OMS gateway needs to be in all the workspaces that you want to connect through it. I haven’t seen this documented anywhere yet, other than you need a working connection to the OMS cloud. It makes sense though because the client uses certificates to communicate to the Azure backend. Apparently the OMS Gateway service is not able to perform this action, most likely because it does not know the keys for the workspace.
For our environment we use a selfservice portal (built in-house) where we are trying to seperate the actual code for performing an action from the front-end code. For our DFS infrastructure the most suitable solution is a PowerShell endpoint with purpose built functions. On of these is setting security groups on DFS links to allow Access Based Enumeration (ABE) to only show links the user actually has access to. For this I need to do a very ugly ‘breakout’ from Powershell and use the DfsUtil.