Blog Post

Security, Compliance, and Identity Blog
6 MIN READ

Syncing and protecting corporate information

MicrosoftSecurityandComplianceTeam's avatar
Sep 08, 2018
First published on CloudBlogs on Jun, 12 2014
Work Folders allow you to maintain control of corporate data by storing it on server file shares while making it available consistently across a user’s multiple devices, including when the user’s device is disconnected from the network. Users want to get at the data—which they consider “theirs”—whenever and where ever they want to work. They often want to work with a local copy, but you need to maintain control of the data, even while making it available. (I’m sensing a recurring theme here.) Have you ever had users email documents to themselves? Have you ever filled a USB flash drive port with epoxy or created a firewall rule to block consumer-based storage platforms (such as Box.com, Dropbox, or Microsoft OneDrive)? With Work Folders, you can stop fighting with users and allow appropriate, secured, protected synchronization of files. Users can sync their work data to their devices, but files can still be classified, so that protection can be applied to sensitive data. Another quite important thing is that a copy of the information is always kept within the corporate realm, available and backed up. For general information about Work Folders, visit Work Folders Overview . In our next and final post on this topic, I’ll look at how you can totally protect your corporate data by removing it from a device if that device is lost, stolen, or taken home when someone leaves the company. But first, let’s look at how to set up Work Folders, and then sync and classify some data.

Setting up Work Folders on a file server

To set up Work Folders, first take care of the basics: Have a domain controller (or better, two!), with proper connectivity such as Domain Name System and Dynamic Host Configuration Protocol servers. You implement Work Folders on file servers, where you set up sync shares. You configure one share per user, and you can enforce a quota. So, set up a Windows Server 2012 R2 computer as the file server. There, add the Work Folders Role service, found under the File and iSCSI Services node of the File and Storage Services role. With the role service installed, a new menu item is created in Server Manager. Launch the New Sync Share Wizard. You can then publish Work Folders directly through a reverse proxy or enforce conditional access by using Active Directory Federation Services, which, in turn, can use device registration information. The wizard will ask you for an existing share or a path for a new Sync Share. Work Folders are designed so that each user assigned to the Sync Share has a personal folder within that share (with NTFS permissions protecting it, of course). This is similar to the “home folder” idea, and many organizations use the same structure. Users can access the Sync Share over Server Message Block (SMB) or Network File Share, as well. As you work through the wizard, most of the options are fairly self-explanatory. A few might warrant some additional details, however. On the Sync Access page, for example, you’re asked to specify the groups that you will allow to access this Sync Share. You can also specify individual users, but that would be silly. This setting controls who can use Work Folders hosted on this share on this server. You are also asked to define the device policies. You can require that the files synced to a device must be stored in an encrypted format or that the device must have an auto-lock with a password. Work Folders use a different encryption key than any other encryption used on the device, which makes it much easier to wipe only the Work Folders, if needed.

Connecting a Windows client and synchronizing files

Now, turn your attention to a Windows 8.1 client and complete the client-side setup. Here are the simplified steps:
  1. Launch Control Panel. Tap System and Security , and then Work Folders .
  2. Provide your work email address. The system uses this address to construct the URL required to reach the File Server.
  3. Enter your logon credentials, if prompted. If the client is a member of the domain, you won’t be prompted for credentials.
  4. Specify the location in which to store the files.
  5. If security policies have been specified on the server, they will appear in the setup wizard. Select the check box to accept them, and then tap Setup Work Folders .
There you have it: You can now access, change, and create folders on any of the devices that you’ve configured and optionally through the SMB share, as well. As you work online, you will see changes reflected quickly across all devices. For a complete step-by-step guide to setting up and testing Work Folders see the Storage Team Blog entry Work Folders Test Lab Deployment , or the documentation page Deploying Work Folders . Note that Windows 7 clients can participate with an optional download , as explained in Work Folders for Windows 7 . Support for other devices is planned but has not yet been announced.

File classification and Work Folders

For extra credit, explore what happens when you configure Automatic File Classification on the file server. Perhaps you have a File Classification rule that all Microsoft Excel spreadsheets must have a Rights Management template applied (using Active Directory Rights Management Services [RMS]). If a user creates a new Excel spreadsheet while working offline, as soon as the client is reconnected and the folders synchronized, the file classification goes into effect, applying the RMS template.

Managing rights to information

AD RMS is an important part of an information protection strategy; and now, it is complemented with Azure RMS. Traditionally, access to a computer file is governed by a discretionary access control list (DACL) that contains entries specifying who can have what types of access to the file. In Windows, DACLs are part of the file system and enforced by the operating system. However, once an authorized user is granted access to read or copy a file, nothing prevents that user from keeping a copy, and then redistributing it to others, whether those other people are authorized or not. RMS helps secure you against such risks. AD RMS protects a file by storing it in an encrypted format. Instead of a simple DACL, permissions are enforced using encryption keys, policies, and licenses. This means that the owner of the document can set rules about how the document can be used, whether it can be printed or redistributed, or even have it expire after a set period of time. Administrators can design templates (e.g., “internal use only” or “do not forward, do not print”) for documents, and the Windows Server 2012 File Classification Infrastructure (FCI) can be used to automatically apply templates based on the location, type or content of the file. For more information about AD RMS, see Active Directory Rights Management Services on TechNet, or the implementation details in AD RMS Overview on MSDN. An example scenario of FCI is featured in Scenario: Get Insight into Your Data by Using Classification . Azure RMS takes the RMS even further. Azure RMS is a cloud-based service that uses Azure AD as an identity store. Azure RMS offers additional flexibility to on-premises AD RMS, including support for not only Microsoft Office and Office 365 but also native viewers on Windows, Windows RT, Windows Phone, iOS, Android, and Macs. Azure RMS supports the protection of many file types, including PDF and XML files, or entire ZIP files that can contain anything. Support remains for Office Documents, e-mail, and SharePoint libraries. And, protection can be extended to users outside of your own organization much more easily than with AD RMS. As with AD RMS, administrators can use templates and policies to protect documents. In fact, individuals outside of a corporate organization can even create a free individual RMS account, allowing your organization to securely share and manage documents with even the smallest of contractors or partners. Get more information about Azure RMS at Azure Rights Management on TechNet. NEXT BLOG POST IN THIS SERIES: Removing corporate data from devices Catch-up with the previous entries in this blog series: Part one: Setting up the environment Part two: Making resources available to users Part three: Registering BYOD devices Learn more about Access and Information Protection here .
Published Sep 08, 2018
Version 1.0
No CommentsBe the first to comment