Monthly Archives: April 2014

Configuring the Azure Rights Management Connector with a Windows FCI File Server

On March 4th, 2014, Microsoft announced the availability of integrating on-premise File Classification Infrastructure (FCI) file server with the Azure Rights Management service using the Azure RMS Connector.

http://blogs.technet.com/b/rms/archive/2014/03/04/windows-server-fci-file-classification-now-supports-azure-rms.aspx

“FCI refers to the File Classification Infrastructure, a capability in Windows Server-based File Servers using the File Server Resource Manager feature which enables the server to scan local files and assess their content to determine if they contain sensitive data, and if they do classify them accordingly by tagging them with classification properties you define. Once files are classified, FCI can also automatically take action on these files, such as applying adequate RMS protection to the files to prevent them from leaking beyond their intended audience. All this happens in the blink of an eye without the users having to take action” 

Note: Files can also be classified manually by modifying the properties of a selected file or folder. This is done on the server-side, or within a Windows 8 client system after a group policy has been applied (http://technet.microsoft.com/en-us/library/dn268284.aspx)

Prerequisites

  • FCI requires a Windows Server running 2012 or 2012 R2.
  • Azure RMS has been activated within your Office 365 Tenant.
  • Directory Sync with your o365 Tenant has been configured.
  • Users that need to work with the RMS documents have been granted the RMS license within the Office 365 Portal
  • Note: In my testing, the RMS Connector cannot be installed on the same server hosting the file share.

image

This walkthrough is for a stand-alone connector installation. For production deployments, a Hardware Load Balancer (HLB) and a minimum of two servers is recommended for high availability.

Download the RMS Connector here http://go.microsoft.com/fwlink/?LinkId=314106

Configuration Steps

Launch setup with Administrative Rights.

image

Enter your Office 365 Tenant Administrator Account information

 

image

 

image

Note: On the next screen, if you are deploying two servers for high availability, do not select Launch connector administrator console to authorize servers at this time. You will select this option after you have installed your second (or final) RMS connector. Instead, run the wizard again on at least one other computer. You must install a minimum of two connectors for HA.

image

To validate the installation, connect to http://<connectoraddress>/_wmcs/certification/servercertification.asmx, replacing <connectoraddress> with the server address or name that has the RMS connector installed. A successful connection displays a ServerCertificationWebService page.

image

Next, authorize the servers that can use the connector. As a best practice, create a group that contains these accounts and specify the group instead of individual server names.

image

Next, select the server role (ex: Exchange, SharePoint or an FCI Server)

image

Next, select an account used to authorize the selected role.

image

Note: It is important that you select computer accounts here, not user accounts. Best practice is to use a group rather than individual servers.

image

When finished adding servers, click close.

 

The next step will be to configure an SSL Certificate on the RMS Connector. To enable the RMS connector to use TLS, on each server that runs the RMS connector, install a server authentication certificate that contains the name that you will use for the connector. For example, if your RMS connector name that you defined in DNS is rmsconnector.contoso.com, deploy a server authentication certificate that contains rmsconnector.contoso.com in the certificate subject as the common name. Or, specify rmsconnector.contoso.com in the certificate alternative name as the DNS value. The certificate does not have to include the name of the server. Then in IIS, bind this certificate to the Default Web Site.

Configuring a Windows Server 2012 or 2012 R2 file server for File Classification Infrastructure to use the connector

Download the RMS Server Configuration Tool script (“GenConnectorConfig.ps1”) from here http://go.microsoft.com/fwlink/?LinkId=314106

Run this on the file servers that you authorized in the previous step. Set the powershell execution policy to allow the script to run if you have not already done so.

Get-help GenConnectorConfig.ps1 –detailed

GenConnectorConfig.ps1 –SetFCI2012 –ConnectorUri http://rmsconnector.contoso.com

After running the tool, Restart the File Server Resource Manager services, which refreshes the RMS templates on the server.

image

You can now Create classification rules and file management tasks to protect documents with RMS policies. See File Server Resource Manager Overview for more information.

For example, after the classification rules have been configured, you can Right-click a file in that folder, and then click Properties. Click the Classification tab, select the resource property you want to tag the folder and click the value, and click OK.

image

You can then create file management tasks to apply RMS protection to documents when the conditions have been met, example: when Department is Research and Development.

image

When this condition is met, on the Action Tab, you can select RMS Encryption and apply the template you would like to use.

image

Now when saving a document into that folder, it will automatically inherit the proper RMS Template.

image

By default, Azure RMS comes with two built-in templates, but you can configure your own through the Azure management portal http://manage.windowsazure.com

After creating a new template, Restart the File Server Resource Manager services, which refreshes the RMS templates on the server.

image

 

 

Next Steps: Configure RMS user activity logging

RMS can log every request that it makes for your organization, which includes requests from users, actions performed by RMS administrators in your organization, and actions performed by Microsoft operators to support your RMS deployment.

If you are only interested in the logging of administration tasks performed in RMS then you can obtain this with the Get-AadrmAdminLog RMS Windows PowerShell cmdlet. Otherwise, if you are interested how users are using RMS, you can use these RMS logs to support the following business scenarios:

  • Analyze for business insights.
    RMS writes logs in W3C extended log format into an Azure storage account that you provide. You can then direct these logs into a repository of your choice (such as a database, an online analytical processing (OLAP) system, or a map-reduce system) to analyze the information and produce reports. As an example, you could identify who is accessing your RMS-protected data. You can determine what RMS-protected data people are accessing, and from what devices and from where. You can find out whether people can successfully read protected content. You can also identify which people have read an important document that was protected.
  • Monitor for abuse.
    RMS logging information is available to you in near-real time, so that you can continuously monitor your company’s use of RMS . 99.9% of logs are available within 15 minutes of an RMS-initiated action.
    For example, you might want to be alerted if there is a sudden increase of people reading RMS-protected data outside standard working hours, which could indicate that a malicious user is collecting information to sell to competitors. Or, if the same user apparently accesses data from two different IP addresses within a short time frame, which could indicate that a user account has been compromised.
  • Perform forensic analysis.
    If you have an information leak, you are likely to be asked who recently accessed specific documents and what information did a suspected person access recently. You can answer these type of questions when you use RMS and logging because people who use protected content must always get an RMS license to open documents and pictures that are protected by RMS, even if these files are moved by email or copied to USB drives or other storage devices. This means that you can use RMS logs as a definitive source of information for forensic analysis when you protect your data by using RMS.

http://technet.microsoft.com/en-us/library/dn529121.aspx

 

References:

Deploying the Azure Rights Management Connector

http://technet.microsoft.com/en-us/library/dn375964.aspx#ConfiguringServers

The Storage Team Blog
http://blogs.technet.com/b/filecab/archive/tags/file+server+resource+manager+_2800_fsrm_2900_/default.aspx

File Server Resource Manager Overview

Hyper-V Replication between two workgroup servers

Enabling Hyper-V between two workgroup servers requires issuing self-signed certificates with makecert.exe and a registry key to bypass the revocation check.

The reason why makecert is required is because the certificate Enhanced Key Usage must support both Client and Server authentication, and the default IIS certificate CSR wizard does not include the client EKU.

Machine #1

1. Generate a root cert:
makecert -pe -n CN=PrimaryTestRootCA -ss root -sr LocalMachine -sky signature -r PrimaryTestRootCA.cer

2. Generate a self-signed cert from the root cert:
makecert.exe -pe -n CN=HV2 -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in PrimaryTestRootCa -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 HV2.cer

3. Disable the revocation checking since that won’t work on self-signed certs:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Machine #2

1. Generate a root cert:
makecert -pe -n CN=RecoveryTestRootCA -ss root -sr LocalMachine -sky signature -r RecoveryTestRootCA.cer

2. Generate a self-signed cert from the root cert:
makecert.exe -pe -n CN=HV1 -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in RecoveryTestRootCa -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 HV1.cer
(Note: even though it outputs a .cer file, it automatically inserts into the LocalMachine certificate store, so there is no additional import step)

3. Copy the PrimaryTestRootCA.cer from Machine #1 and then run this command:  certutil -addstore -f  Root “PrimaryTestRootCA.cer”

4. Copy the RecoveryTestRootCA.cer from Machine 2 and then run certutil -addstore -f  Root RecoveryTestRootCA.cer

5. Disable the revocation checking since that won’t work on self-signed certs:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

6. Now you can select the self-signed certificate in replication on both servers.

image

Important: if you have windows firewall enabled, create an allow rule for TCP 443 on both servers:

netsh advfirewall firewall add rule name=”Https Replica in” dir=in protocol=TCP localport=443 action=allow

 

Credits to these two blogs for helping me figure this out:

http://jsmcomputers.biz/wp/?p=360  (<- The only problem with his blog is the quotes “” do not work in his command-line syntax, those need to be removed otherwise you get an error “CryptCertStrToNameW failed => 0x80092023 (-2146885597)”

http://blogs.technet.com/b/virtualization/archive/2013/04/13/hyper-v-replica-certificate-based-authentication-makecert.aspx