Quick Tips: Programmatically emptying the Temp folder for all user profiles in a terminal server.

I ended up needing to do this last week, we have a LOB application that people access via Terminal Services, and it doesn’t clean up after itself in the Temp folder, which causes the application to act up. Can’t get the developers to fix the problem so it’s on us. The existing fix was one batch file, tied to one scheduled task, for every user (50+) of the terminal server. Nightmare to keep maintained.

So I built a simple powershell script, one script for all user profiles.

for(;;) {
try {
Set-Location "C:\Users"
Remove-Item ".\*\AppData\Local\Temp\*" -recurse -force
catch {
# EventSentry will watch for Powershell dying.

# wait for a minute
Start-Sleep 60

Then I created a scheduled task to have Powershell run on startup with the argument -file Path:\to\script.ps1 and had it run as SYSTEM with highest privileges. Since this was the first time using ps1 files on this server I also needed to Set-ExecutionPolicy RemoteSigned.

Quick Tips: Share Permissions do more than you think.

While rebuilding a piece of my lab for file server and DFS services, I had an odd set of symptoms. I had a user in a security group that was not set to be able to change permissions, and no ability to take ownership, in the NTFS permissions. Yet they were able to add permissions to give others elevated access, or even elevate their own access.

It turns out I’d forgotten the share permission side, where this still had some debug settings; in particular, that “Authenticated Users” had full control. Have you ever really messed with those share permissions? Usually we rush right on and do Everyone -> Full Control and then lock it down with NTFS permissions later. But, have you ever tried just doing Change and Read and leaving Full Control off? It’s actually what you’re usually trying to accomplish, and gives you a little head start in that you don’t have to hope you don’t get a clever end-user later that elevates their own NTFS permissions.

Ransomware is the future.

When I first started fighting ransomware in late 2013, I had a premonition that this was something serious. While CryptoLocker was rather easily defeated in the enterprise and ultimately killed by killing the botnet, media outlets and tech sites ran with the story. It showed this small group making millions and millions of dollars. Guess what? More people started writing ransomware.

Cut to now. Ransomware-as-a-service is a real thing you can buy, some variants have live chat support to receive payment, and we routinely see new versions with bugfixes and feature-adds. One of the last major flaws in ransomware, the inability to enumerate non-mapped network shares, was overcome in the latest Locky build that calls WNetOpenEnum() to attempt to traverse every share on the network.

For several years, the endgame was more abstract. Hit the PC with your rootkit, join it to your botnet, sell botnet access to spammers for a fee. Now they can cut out the middle man and have less overhead, since there’s not a need for constant command-control oversight. It’s a path to riches hampered only by the still-high knowledge barrier to acquire and send bitcoin. And by affecting the user’s files, rather than a popup about the FBI or TotesLegit AntiVirus which can simply be fixed by backing up the data and nuking the PC, you’ve got them at your mercy.

This is going to get worse way before it gets better. You’ll see builds that try to invoke APIs for popular cloud storage providers to delete the versioning. They’ll find ways to avoid taking ownership of a file to quickly spot the vector of infection. While it’s almost impossible to be truly proactive to effectively block ransomware, there are things that can be done.

  • Avoid mapping your drives and hide your network shares. WNetOpenEnum() will not enumerate hidden shares. This is as simple as appending a $ to your share name.
  • Work from the principle of least permission. Very few organizations need a share whereby the Everyone group has Full Control. Delegate write access only where it’s needed, don’t allow them to change ownership of files unless it’s a must.
  • Be vigilant and aggressive in blocking file extensions via email. If you’re not blocking .js, .wsf, or scanning the contents of .zip files, you’re not done. Consider screening ZIP files outright. Consider if you can abolish .doc and .rtf in favor of .docx which cannot contain macros.
  • Install ad-blockers and script-blockers as standard loadout. Drive-by malware is out of control right now. Cut off the vector of infection. I use uBlock Origin which is easy to disable case-by-case and offers niceties like element blockers.
  • Install the old CryptoLocker Software Restriction Policies which will block some rootkit-based malware from working effectively. You can create a similar rule for %LocalAppData%\*.exe and %LocalAppData%\*\*.exe as well. It was pointed out in the reddit comments, that if it’s at all feasible, run on a whitelist approach instead of a blacklist. It’s more time-intensive but much safer.
  • Stay up-to-date on the latest ransomware news, how they operate, and what the decrypt instruction filenames are. These can be added to file screens with FSRM to execute a command to kill the share. Simply disabling the affected user is not enough without also forcing them to log off.
  • Backups. Having good, working, versionable, cold-store, tested backups makes this whole thing a minor irritation rather than a catastrophe. Even Windows Server Backup on a Wal-Mart External USB drive is better than nothing. Crashplan does unlimited versioned backups with unlimited retention at a flat rate, and there’s a Linux agent as well. Hell, Dropbox does versioned backups. Get something.
  • [Added 5/12/2016] For some non-program (WinPE) viruses, you can change the default behavior of some extensions to open in Notepad rather than the original vulnerable target. A guide is here.

Ransomware has evolved a lot in just a couple of years, and the end is nowhere in sight. Get your defenses up, and know the enemy. There’s a lot less heartache doing the prevention before you’re hit than after.

Setting up secure Home Folders without touching AD.

In preparing for a new file server schema, I’ve been playing with home folders and quotas. I wanted to come up with a “home folder” solution that met a couple needs:

  • Worked well with Windows 7 through 10
  • Did not involve the client support team having to set the home folder in each user’s AD profile
  • Did not rely on folder redirection or roaming profiles
  • Set-and-forget implementation and minimal headache to manage in the event of data going missing out of a directory
  • Secure with no ability for users to see other users shares or even be aware of them, or to delegate permissions to other users
  • Does not use a mapped drive, to mitigate against current ransomware trends
  • Can be managed with File Server Resource Manager for quotas and file screening.

After three days in the lab, I came up with a solution that accomplishes all of these goals. It takes a particular combination of NTFS permissions, Access Based Enumeration, and some group policy, and then whatever you want to do with FSRM. The core concept will work without ABE and FSRM, that’s just a cleanliness thing for other related projects we’re planning.

Setting up the share:

Set up your share however you normally do it. I like making shares for home folders hidden, e.g., \\FS01\UserShares$. Give the Authenticated Users object Full Control. We’ll get more restrictive with NTFS permissions.

The NTFS permissions:

This is the secret sauce to get the security piece working correctly. We’re going to stack a few permissions to balance functionality and security.

Working from the base of your User Shares folder, right click, Properties, Security, Advanced.

  1. Disable Inheritance and remove all inherited permissions.
  2. Add SYSTEM and give it Full Control over “This folder, subfolders and files”.
  3. Optionally, have a security group that will have permissions to browse all shares for the purposes of investigation or data recovery, and give it Full Control over “This folder, subfolders and files.”
  4. Add Authenticated Users, specify that it applies to this folder only, and switch to advanced permissions. Give the object: Traverse folder / execute file, List folder / read data, Read attributes, Read extended attributes, Create folders / append data, Write attributes, Write extended attributes, Read permissions.
  5. Add the OWNER RIGHTS object, specify that it applies to subfolders and files only, and check Modify on top of the existing check boxes.

Before I go any further I want to point out two negatives to the implementation:

  • It does not prevent the user from deleting their home folder, assuming they figure out how to get to the parent folder.
  • It does not prevent the user from creating another folder in the UserShares$ share, assuming they could figure out how to get there.

In our case, those two caveats are acceptable for us. If you’re wondering why we’re using OWNER RIGHTS instead of the usual CREATOR OWNER object, doing the latter will allow the users to delegate permissions to any valid AD object (i.e., letting them have others browse their home folder). OWNER RIGHTS does not. OWNER RIGHTS is available as an object starting with Server 2008 and Windows Vista.

Building the Group Policy:

So now that folders will have the right permissions when a user makes them, let’s have them get created automatically, and put in a convenient place on the workstation.

  1. In Group Policy Management Center, create a new policy for users.
  2. User Configuration -> Preferences -> Windows Settings -> Folders -> New Folder
  3. Action: Create, Path: \\FS01\UserShares$\%LOGONUSER%
  4. Under the Common tab, check the box for “Run in logged-on user’s security context (user policy option)” or else the computer account will own the folder.
  5. User Configuration -> Preferences -> Windows Settings -> Shortcuts -> New Shortcut
  6. Action: Update, Name: Home Folder, Target type: File System Object, Location: My Network Places, Target path: \\FS01\UserShares$\%LOGONUSER%, Icon index: 9
  7. Under the Common tab, check the box for “Run in logged-on user’s security context (user policy option)”

Run a gpupdate /force from the DC and restart your workstation to test. What you should see on logon is a new item in Network Locations called Home Folder. If you check the file server, you should see a new folder under your share with the username of your account you’re testing with.

Observe a few things here:

  • The user can’t access any other shares, but they can see them. We will change this later.
  • The user can’t drag their folder into another user’s folder.
  • The user can’t change the permissions of their folder, or any subfolder or file within their folder.

At this point you have a working solution if you don’t care about file quotas, file screening, or hiding folders the user can’t read. For the rest of it, read on.

Feature add: Access-Based Enumeration

ABE is an under-loved feature of Windows Server and has been in since 2003. In a nutshell, if a user has no access to a folder within a share, it will not be displayed to the user if ABE is turned on for the share. The exact method to enable it varies by the OS but in Server 2012 and R2, it requires the File Server role to be enabled. Though there’s a gray checkbox indicating some of the roles are already on, this is not one out of the box. Once it’s added, you’ll be able to go to Server Manager -> File and Storage services -> Shares. Right click your UserShares$ share and go to Properties. Under the tab for Settings, check the box for “Enable access-based enumeration” and hit OK. That’s all there is to it. Create another test logon, and then hit your UserShares$ share with Explorer. You will only see your own share, and not any other user home folders.

Feature add: Quotas

I feel like most people are going to want some sort of quota system in place for this. This requires the File Server Resource Manager role enabled. You could manage this from Server Manager but that way is very rigid and doesn’t allow for exceptions for different users.

Once it’s enabled, you’re going to want to start with a Quota Template in FSRM. The big decisions are the amounts, whether it’s a hard or soft cap, and if there are actions you want taken (an email, something in the event log, or an arbitrary command) at a certain percentage full. Once the template is completed, go ahead and add a quota. Under Quota path, browse to the root folder where your home folders reside. Hit the radio button that reads “Auto apply template and create quotas on existing and new subfolders.” Then under quota properties, choose to “Derive properties from this quota template” and select the template you just created. Then hit Create. That’s about all you’ve gotta do.

You may also wish to make a more relaxed quota for power users. Make another template, then under Quotas, hit Filter, choose All and All, and hit OK. You should see all your home folders individually laid out. Choose your example power user and right click, then Edit Quota Properties. At the top, choose to “Copy properties from quota template,” select your relaxed template, and hit Copy. If you don’t hit copy, nothing happens. Then hit OK.

If you wish to disable quotas altogether for a user,  choose that user in Quotas, and at the action bar on the right, hit Disable Quotas. Simple.

Feature add: File Screening

File screening lets you block certain extensions from being placed in a folder. It’s best to do this early and adjust later if you’re rolling out home folders and are considering implementing this. For us, we don’t wish to use expensive server storage backing up Jimmy Buffett’s Greatest Hits and the vacation pictures that Stan from Accounting took eight years ago. You can use File Screening in either a whitelist or blacklist function. Both ways involve the File Screening Management section of File Server Resource Manager (FSRM), which you will need to enable as a Role.

Option A: Blacklist

This may be easier in the long run, albeit less secure. Head to File Groups under File Screening Management, you’ll see a number of groups already made. A fair warning, under Audio and Video Files, *.m4a is not included by default and should probably be added by you, and *.mp4 is not in by default in WS2008 R2 when I last looked. Also, Executable Files includes *.ps1 and *.js which may give your developers some grief. Once you’ve got your groups dialed in, you can build the template to screen against. Under File Screen Templates, choose Create File Screen Template via the Action bar. Here, you can choose multiple file groups to add to the template, whether to hard-screen or simply monitor, and also how to handle exceptions. You have to fill out one tab at a time because reasons. Once that’s done, you can actually do the screening under File Screens -> Create File Screen. Browse to the base directory for your home folders, and choose the template you created under “Derive properties from this file screen template.” Then hit create. It should take effect immediately.

File Screen Exceptions are for power users that need access to one or more of your blocked extensions. Choose their home folder, and either create the file group on the fly or build it out with the extensions to allow.

Option B: Whitelist

This may take more care and feeding but will result in a more secure environment, and this can easily be extended to larger file shares to help alert about malware. Start in File Groups under File Screening Management in FSRM. Create a File Group and call it Everything. Enter * in “Files to include” and hit Add. Then go to File Screens -> Create File Screen. Browse to your base home folders directory and choose to “Define custom file screen properties” and hit Custom Properties. Check the box for your “Everything” file group, and determine what notifications you wish to be sent in the other tabs, then hit OK.

Now you’re going to create the exceptions, which in this case serve as a whitelist. Use the same base home folders directory as the Exception Path, and then check the file groups you want to allow through. I highly recommend you allow the Temporary Files group, or Office files will not work right. Also bear in mind, *.pdf is not specified in any existing group by default. You may wish to go the route of making an Exception Group in File Groups to have everything in one place that all employees will need access to.

When power users need exceptions, you’ll follow the same process, just with the exception path as their home folder. You could theoretically not screen someone at all by choosing your Everything object as an exception group.


What you’re left with is a home folder structure that’s very secure, with entirely automated provisioning and screening, accessible to end-users, compatible with all supported versions of Windows, and minimizes your exposure to ransomware by avoiding mapping a drive.

I hope this was informative, it was quite a constructive lab session.