Using profile disk (UDP) on terminal server cant save to AppData\Roaming\Adobe\Flash Player\NativeCache

[troelsmajlandt]

We are using Terminal Server (rdp) to an server farm.

The user login and the \users\ are setup with profile disk (UDP)

User Profile Disks (UPD) were introduced in Windows Server 2012 and intended to replace the standard method of managing user data with roaming profiles. Unlike roaming profiles, a UPD is not an actual directory containing user profile data.

"User profile disks store user and application data on a single virtual disk that is dedicated to one user’s profile. User profile disks provide an easy way to store the user settings and data on a separate virtual disk that is reattached at logon, so the user data isn’t discarded when the virtual machine rolls back".

But my problem is that the user cant for some reason save content to \AppData\Roaming\Adobe\Flash Player\NativeCache so some webpages dosent work correct.

It is not a rights issue - the user have Full Control to the directory, and are able to create and delete files there manually.

[This post moved from Adobe Shockwave Player to Using Flash Player by Moderator.]

[jeromiec83223024]

Check out the EnableInsecureJunctionBehavior and EnableLocalAppData flags on pp. 58 of the System Ad...

https://www.adobe.com/content/dam/acom/en/devnet/flashplayer/articles/flash_player_admin_guide/pdf/f...

[troelsmajlandt]

Hi

Tx for the answer.

But this goes more to the supplier of the Web-app we are using, i am not sure that I can get them to try to change this.

I was more looking for an answer why flash behave different on profiledisk/udp than normal roaming profile on an RDP solution.

But ill try to send the info to the supplier of the web-app.

[jeromiec83223024]

No, this is client-side config flag for Flash Player that you would need to push out to machines in your environment via an mms:cfg file.  This issue has nothing to do with the content, and is most likely beyond the ability of the content provider to control.

Redirecting the user folder to a path that traverses a junction point creates the potential for malicious content to write to arbitrary locations in conditions where it isn't managed well, and we block the behavior by default to miitigate the potential for misuse at an ecosystem level.

You can either configure clients running Flash Player to keep data on the user's local machine (which avoids the issue with Windows junctions entirely), or disable the mitigation and just proceed woth caution.

Trying this on a teat client is pretty easy, and should validate my recommendation.  There's a lot of stuff in the guide about managing Flash Player distribution and configuration at enterprise scales, which will be relevant.

[troelsmajlandt]

Hi

Again tx. for the quick answer - I'll look into it.

Any chance that you have an example mms.cfg i can get an get startet on - an perhaps where to place it.

I am not that technical 🙂

[jeromiec83223024 · Accepted solution]

It's just a super simple text file. There's a section on it in the admin guide.  You're probably going to need some help from someone with administraion skills on the best strategy for distributing that configuration file, once you confirm it works.

[troelsmajlandt]

Super,

Your info/hint got the trick.

This in mms.cfg (file is already there)

EnableLocalAppData = 1

EnableInsecureJunctionBehavior=1

/Troels

[jeromiec83223024]

Ideally, you would only need the EnableLocalAppData=1 directive.  It should work, and will keep the related security mitigation active.

We have a number of security mitigations that we keep behind EnableInsecure<whatever> flags for compatibility.  These flags are sometimes valuable to specific enterprises, where administrators understand the trade-offs and have the resources to constrain risks via other mechanisms in their environments.  We use EnableInsecure as the prefix to communicate that "this is probably a bad idea", but sometimes specific environmental constraints require their use.  If you can avoid using them, that's the best possible outcome.  If you can't, then it's important to understand issues around junction traversal (or whatever the legacy functionality you're enabling is) and ensure that they're appropriately mitigated or monitored in your environment.

If it's not clear, this is happening in your environment because the path to your user's redirected home folder requires traversing a junction (it's similar to a symlink on Linux, but it's not precisely equivalent).  What you're doing pretty standard practice when redirecting user profiles to networked storage, but when you're talking about an application like Flash Player -- where our primary job is executing untrusted content -- we want to constrain potential attack surfaces to the extent possible.