Setup Azure RMS File Protection (Encryption) and File Classification Infrastructure (FCI) with On-Prem File Servers


Setup Azure RMS File Protection (Encryption) and File Classification Infrastructure (FCI) with On-Prem File Servers

In our new world of highly mobile access to loosely coupled services it’s far easier for a user, who has legitimate access to the data, to accidentally move it to a storage location that doesn’t have your corporate data protections: They move a file from the file server to their personal cloud storage for example. Through Enterprise Management Suite we have a solution to this problem, Azure RMS. Traditionally RMS was less than simple to deploy and required users to do something to protect their files. Thankfully Azure RMS is substantially different, there’s a ton of documentation you can read for more info on TechNet which helps you to deploy Azure RMS but here I’m bringing together the guides for building out File Classification Infrastructure and Azure RMS.

Quick Azure RMS Primer

RMS connector architecture Azure RMS allows you to protect documents (and now other types of files) with encryption, identity and authorization policies and those files can only be accessed as long as a connection to the Azure RMS service can be made and the user is authorized to read or write the document. A great example is in the Azure TechNet library:

you can configure a file so that it can be accessed only by people in your organization, or control whether the file can be edited, or restricted to read-only, or prevent it from being printed. You can configure emails similarly, and in addition, prevent them from being forwarded or prevent the use of the Reply All option. These protection tasks can be simplified and streamlined for your end users by using standardized policy templates. Azure Rights Management is a cloud service, and is integrated into other Microsoft cloud services and applications for simple ease-of-use and persistent protection. tweet


Quick FCI Primer

File Classification Infrastructure runs on Windows Server 2012 (R2) and looks for files that match specific rules that admins have configured. When a file matches your rule it is classified in terms you’ve set, such as in my example below when “Confidential” is detected in a document that document is classified as “High Impact”. File Classification runs on a schedule and when new files are created if you so desire. In addition to the Classification Rule a File Management Rule runs to take that classification and apply something to it, in our case RMS protection. The actual classifiers are passed down from AD on-prem using Dynamic Access Control, which can also provide conditional access rules – but that’s beyond the scope of this post.

Configuring a Lab

Here I’m explaining how I configured my lab, but it’s basically the same process for production. I’m assuming that Azure AD Premium licensing has been applied to the Azure AD tenenant. Trials are free. Azure AD Premium is required because the Azure AD RMS Connector is only available with this licensing option. I’m also using Windows Server 2012 R2 for my file servers and for my connector server. I configure my lab using PowerShell as below, everything can be done through the UI – I prefer the brave new world of Infrastructure as Code wherever possible.

#Configure DAC in AD on-premises
Invoke-Command -ComputerName -ScriptBlock{
Set-ADResourceProperty -Enabled:$true -Identity:"CN=Impact_MS,CN=Resource Properties,CN=Claims Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com" -Server:""
This first section will configure the AD Resource properties that we need to use for file classification. I do it using an invoke-command because I’m probably not running this on a domain controller, or somewhere with RSAT installed in my case.
#Configure FSRM on App Server, including a classification rule and making a Wokfolders folder if needed
Invoke-Command -ComputerName -ScriptBlock {
Get-WindowsFeature *fs-resource* |Install-WindowsFeature -IncludeManagementTools
if(-not (test-path d:\WorkFolders -PathType Any)){New-Item -Path d:\WorkFolders -ItemType Directory}
Note: I’ve split this scriptblock to better explain it. First I invoke to run this section on my file server (called APP in my case). I then add the File Server Resource Manager feature to the server. Finally above I check to see if the folder I want to monitor exists, if it doesn’t I create it…I kind of love the simplicity of this line.
$date = Get-Date
$AutomaticClassificationScheduledTask = New-FsrmScheduledTask -Time $date -Weekly @(3, 2, 4, 5,1,6,0) -RunDuration 0;
Set-FsrmClassification -Continuous -schedule $AutomaticClassificationScheduledTask
New-FSRMClassificationRule -Name "High Business Impact" -Property "Impact_MS" -Description "Determines if the document has a high business impact based on the presence of the string 'Confidential'" -PropertyValue "3000" -Namespace @(“D:\WorkFolders”) -ClassificationMechanism "Content Classifier" -Parameters @("StringEx=Min=1;Expr=Confidential") -ReevaluateProperty Overwrite
Here I pull the updated properties from AD, set todays date and setup an automated FSRM task to run  my classification rules. I then define my rule to run “continuously”, i.e. on new file write, add it to the scheduled task. Finally I define the new rule…this last part is actually easier through the UI since the syntax is long, but the documentation on it is on TechNet.
#Now download and install the connector on the connector server
# authorize the app server if not already done
The above commented section cannot be done in PowerShell. The connector needs to be downloaded and installed on your connector server (there should be two of them, and they should be balanced with NLB for availability) – in the next section the sync.corp.contoso hostname should be the DNS name of the NLB cluster. Of course for a lab you only need one server to run as the Azure RMS Connector.
# Run this line on the APP server
& '\\dc\c$\DemoContent\GenConnectorConfig.ps1' -ConnectorUri– -SetFCI2012
Above again is almost manual. I run this script on my file server so this works for me. The GenConnectorConfig script is downloaded at the same time as the Connector software from the same link. What we are doing here is configuring the file server to look to the Azure RMS Connector server (which in turn looks to Azure RMS) for RMS templates. The –setFCI2012 switch sets things up for FCI but the script can also be used to configure on-prem SharePoint and Exchange to use Azure RMS via the connector. Almost done.
# Now configure the Management Task in FSRM (the following will work too or use as a backup)
$fmjRmsEncryption = New-FSRMFmjAction -Type 'Rms' -RmsTemplate 'FakeURLUSA - Confidential'
$fmjCondition1 = New-FSRMFmjCondition -Property 'Impact_MS' -Condition 'Equal' –Value '3000'
$date = get-date
$schedule = New-FsrmScheduledTask -Time $date -Weekly @('Sunday')
$fmj1=New-FSRMFileManagementJob -Name "High Business Impact" -Description "Automatic RMS protection for high business impact documents" -Namespace @('D:\WorkFolders') -Action $fmjRmsEncryption -Schedule $schedule -Continuous -Condition @($fmjCondition1)
Above finally sets up the file management task to apply RMS protection, using the FakeURLUSA Confidential RMS template to any files classified as High Business Impact.
Start-FsrmFileManagementJob -Name "High Business Impact"
Finally the above two lines will run the required classification and management jobs on-demand.

File Protection.Done. < 20 lines of PowerShell

That’s all there is to it. Now any Office file saved into that folder with “Confidential” in the body will be encrypted, but it strikes me that in our highly mobile world you might want to be able to protect every file in the folder if they are company information – of course once a file is protected with RMS the file can no longer be parsed by FSRM and FCI. Because this is RMS the files can be opened anywhere the user tries to open the file and contact Azure RMS to read them…of course if a cloud storage service that doesn’t support RMS tries to read the files (to sell Ads or something) they will be corrupted…which is kind of the point.

Share with your network so they know you're THE mobility expert
Tweet about this on Twitter18Share on Google+3Share on LinkedIn27Share on Facebook7Buffer this pageDigg thisShare on StumbleUpon0Pin on Pinterest0Email this to someone
Simon May is an Infrastructure Technology Evangelist at Microsoft concentrating on Devices and Services but with special interests in deployment and device management. Simon is a professional public speaker and the author of several books on Windows. Opinions on this blog are his own.