Hi,
We tried to reproduce this behavior in our own Parallels RAS lab.
We published Active Directory Users and Computers using:
Program:
C:\Windows\System32\mmc.exe
Parameters:
C:\Windows\System32\dsa.msc
The application is correctly executed in the user context. When a user is not allowed to access the published application through RAS filtering, the shortcut is not visible and the user cannot launch the published resource from the RAS client/portal.
So, based on our test, RAS filtering seems to work as expected.
One important point is that ADUC is only an MMC snap-in. If the user has access to another published desktop or another application that allows launching mmc.exe, Explorer, cmd, PowerShell, or any kind of shell escape, they may still be able to open MMC manually and add the "Active Directory Users and Computers" snap-in from there.
In that case, the process will still appear as mmc.exe running inside the user session, but it does not necessarily mean that the restricted RAS published application was launched.
I would suggest checking:
- whether ADUC appears as a running published resource in RAS, or only as a Windows process
- the parent process of mmc.exe on the RDSH server
- Windows process creation events, especially Event ID 4688 with command line auditing enabled
- whether the user has access to a full desktop or another published application that allows starting MMC
- whether RSAT / ADUC is installed on RDSH servers used by standard users
From a security point of view, I would not rely only on RAS publishing rules for this kind of sensitive tool. ADUC should ideally be installed only on dedicated admin RDSH servers, with logon restricted to admin users. Alternatively, MMC and sensitive snap-ins should be restricted using GPO, AppLocker, or WDAC.
So my current understanding is: this may not be a RAS authorization bypass, but rather a Windows/MMC lockdown issue on the RDSH server.
That's all folks !
Click to expand...