DEM Path-based Application Blocking not listening to allow folder

[dvdende]

Hi,

For some reason DEM does not seem to adhere to an Application Blocking setting when path-based is used in combination with select a folder.

In the below image I've made a Allow selection for two folders of which I want to allow all .exe files inside. When starting an application from within this folder I'm still getting the "Your application is blocked" popup.

When I use Hash-based and select the individual application files themselves in DEM I can start the application without any problems.

Does anyone know how to solve this?

DEM version = 2009

 

[dvdende]

Additional information:

I found that the easiest way to replicate the issue is to redirect the user folder to a network drive and mount it as a drive letter (say H:\).

When adding an .exe to this folder and adding the executable (or folder) to Application Blocking and Privilege Elevation it becomes clear that Privilege Elevation works (you get a popup to ask you to make sure you want to elevate) but the application is still being blocked by Application Blocking.

Only Hash-based seems te work (non path specfic) but seeing the application I want to allow is in the process of being developed the hash keeps changing.

[DEMdev]

Hi @dvdende,

Is the launch allowed when users access it via the UNC path?

[dvdende]

Hi @DEMdev ,

No it is not. There is no way to start the application.
Only when changed to hash-based does the application start.

[shampoo77]

Same here. My DFS share won't be allowed anymore:

\\domain\dfs\sdrive\* allow

this gets blocked: Process 'KeePass.exe' blocked from path '\Device\Mup\fs-02\sdrive$\Keepass\'.

[DEMdev]

Hi @dvdende,

Could you send me (via private message) a copy of the application blocking configuration files in use, and a FlexEngine log file at log level DEBUG covering a full session from logon till logoff in which you tried (and failed) to launch an "allowed" application via a UNC path?

[dvdende]

@DEMdev,

I'll send you the information by IM.

For some more information. When trying to open de application from H:\ (homeshare) I get the DEM blocking popup.
When trying to open it using the full UNC path I get a more Windows like error, see below. But when I disable Application Blocking I can start the application from both paths without any problem.

[DEMdev]

Hi @shampoo77,

You might be on to something here, with your remark about DFS... I'm fully aware that it removes some of the value of DFS namespaces, but could you perform a test by also adding the actual folder targets (i.e. the "real" shares) as allowed paths?

@dvdende, would you happen to be using DFS as well? Also, thank you for the additional data point of the "Windows like error"; not sure what's happening there, so that's something else for us to figure out.

[dvdende]

@DEMdev,

Yep, correct we are using DFS as well.

[shampoo77]

1st test looks promising:

\\domain\dfs\sdrive\* allow
Added:
\\FS-02\sdrive$\* allow

Now it works. Could be a potential bug.

Old share server(windows 2012R2) works with DFS allow path in application blocking
New share server DFS (Fully patched windows server 2019) does not work with DFS allow path in application blocking, but seems to do so with an actual DFS targetlink. ¯\_(ツ)_/¯

FYI SR21235193207

[DEMdev]

Hi @shampoo77,

> Could be a potential bug.

I appreciate your "could be", but, yeah, that's a bug... We're definitely aware of DFS in general, as the DFS-related log messages for config share and profile archive paths show, but it seems that we completely overlooked it for application blocking...

Thank you for the additional remarks about DFS on 2012R2 vs 2019 – that's good to know (and might be why we did not run into this previously.) @dvdende, which version are you using for your file servers?

I'll pick this up internally, and will inform the TSE that's working on SR21235193207. @dvdende, in case you want to file a support ticket (or already have done so), feel free to post or PM me the SR# so I can do the same there.

To be honest, I don't expect we'll be able to address this soon, so I hope the workaround of also adding the actual DFS link targets as allowed folders isn't too painful in the meantime.

[dvdende]

@DEMdev,

File servers are Windows Server 2019 Standard.

@shampoo77, which Windows version are your DFS server, seeing the mine are a little old (2012 R2) and will be replaced this weekend.

I've added the direct link to the file as well but still aren't able to start the application

After correcting my error and adding %username% it works when using the UNC path. In most cases this will be an OK workaround but in my case it's making my life difficult.

Visual Studio projects are in the redirected user profile location Documents. When running Visual Studio our users will open it from C:\Users\..... and therefor will not be accessing the application using \\fileservername\etc.

Seeing you are saying it's a known bug we will try and work around it so far as possible.

Thanks for the information @shampoo77 

[DEMdev]

Hi @dvdende,

Thanks for testing the workaround of also adding the DFS link targets, and happy to hear that that works for you as well.

The fact that we don't support launches from a drive letter is a known limitation. If we are able to remove that limitation as part of the changes required to fix the newly discovered DFS-related issue, we will most definitely do so.

In the meantime, thanks (and apologies...) to @shampoo77 and you for bringing the DFS issue to our attention.

[Ray_handels]

Hello @DEMdev 

has been a while since I have been on the forums, been a bit busy :).

We are seeing this exact same issue on a 2019 fileserver with DFS. When adding the actual location to the fileserver the application is not being blocked but still, if we go to the dfs share we cannot open the application there. With the exact same issue as noted in the other posts that we don't see the dem error message but with th group policy message.

Any idea on a solution??

[ifsdd]

Hello Team,

Thanks for digging out the problem. Now 2023, two years later and the issue is still alive, isn't it?

Is there any progress in there? We are currently experiencing the problem ourselves with a DFS on 2019.

The workaround with publisher based exception or direct UNC path to fileserver works. Better would be using the DFS path.

[DEMdev]

Hi @ifsdd,

What version of DEM are you using, and do you have the advanced DFS namespace support for application blocking setting enabled?

The original code that's behind that configuration setting left some corner cases uncovered, but we fixed that in DEM 2209.

[TomH201110141]

Hi @DEMdev 

it's DEM version 2103 and yes DFS namespace support for application blocking is enabled.

I think this version will be the reason for the problem. Upgrade is planned. Thanks for clarification.

It's me @ifsdd (company account vs. personal account)

[DEMdev]

Hi @TomH201110141 AKA @ifsdd :),

The original (and, as we now know, limited) DFS namespace support for application blocking workaround was introduced in DEM 2111, so if you're currently using DEM 2103 that setting would not have any effect at all.

Either way, good to hear that the upgrade is planned – please keep us posted.