Body:
Using Azure RMS for Office 365 is a great way to secure important information within your environment, and Microsoft uses a 3rd party to ensure that the encryption keys are secure from even Microsoft employees themselves. “Well great,” you might say, “but what’s the stop them from just accessing the 3rd party encryption keys and decoding the data themselves?” Obviously that is a technical possibility, but auditing and logging ensure that proper procedures are being followed. OK, maybe you’re not the kind of company that’s worried about “Big Brother” reading your encrypted data and just want to see who within your company is following your own procedures? It turns out auditing and logging provide that solution as well! So, since auditing and logging are so important, Microsoft has made the logs available to you. Per TechNet, “ 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.”
I won’t go in to greater detail about business cases here, but I will go in to how logging is enabled and logs are accessed. RMS logging, much like mailbox auditing in Exchange Online, is not enabled by default. There are a set of pre-requisites that must be met and steps taken to ensure its availability to you.
Make sure the follow pre-requisites are met:
| Requirement | More information |
|---|---|
| An IT-managed Microsoft RMS subscription | You must have a Microsoft RMS subscription that is managed by your organization. Organizations that use RMS for individuals cannot use RMS logging.If your organization contains users who use RMS for individuals, RMS logging provides a very compelling business reason to convert RMS for individuals into a Microsoft RMS subscription. |
| Windows Azure subscription | You must have a subscription to Windows Azure and sufficient storage on Windows Azure for your RMS logs. |
| Windows PowerShell for rights management | If you haven’t already done so, download and configure Windows PowerShell for rights management. You will use Windows PowerShell cmdlets to configure and manage your RMS logs. |
The bold part is important; RMS logs can only be stored on Windows Azure storage. I created a Storage Account in my Azure organization to support this pre-requisite:
I grabbed my Primary Access Key (it’s not the full key, don’t get any ideas!):
Next, because I didn’t plan ahead, I installed the Windows Azure AD (AAD) RMS PowerShell module (this can be done ahead of time):
And then, finally, ran through the cmdlets documented in the earlier referenced TechNet link:
You can see here that the -storageaccount variable accepts the simple name given when the storage account was created.
So now that logging is enabled, I want to see what it gets me. I ran through some SharePoint Online file access attempts, as well as a screen print attempt with an Exchange Online, RMS-protected email. On a side note, screen prints aren’t supported!
Now that I’ve finished some actions, I open up my PS module and run Get-AadrmUsageLog -path C:\logs, only to get this:
I closed the module, waited 5 minutes and then opened it again (in Elevated Mode, to be sure). Success! Lesson learned; logs are not immediately available for the latest actions. Here’s what I got for my Outlook access (the *s are deliberate):
#Software: RMS
#Version: 1.0
#Fields: date time row-id request-type user-id result correlation-id content-id c-info c-ip
2013-12-10 19:09:56 d**0bd58-a382-47c4-ab2f-e46db34eea62 FindServiceLocationsForUser ‘testuser@****.onmicrosoft.com’ ‘Success’ 412**b9a-8129-4566-b1cc-aff143***1a6 – ‘MSIPC;version=1.0.621.176;AppName=OUTLOOK.EXE;AppVersion=15.0.4551.1004;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=amd64′ 10*.20*.*00.*6
2013-12-10 19:09:57 8724254e-9c21-4d2c-abdd-82***13b8228 GetClientLicensorCert ‘testuser@****.onmicrosoft.com’ ‘Success’ 84efc**5-dc39-458c-86ec-3c***d2c470d – ‘MSIPC;version=1.0.621.176;AppName=OUTLOOK.EXE;AppVersion=15.0.4551.1004;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=amd64′ 10*.20*.*00.*6
2013-12-10 19:09:58 413**457-b5ff-4bd7-ae09-0a***74e8761 AcquireTemplateInformation ” ‘Success’ ecee*a36-deea-4f62-8967-9fbc***8e9f6 – ‘MSIPC;version=1.0.621.176;AppName=OUTLOOK.EXE;AppVersion=15.0.4551.1004;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=amd64′ 10*.20*.*00.*6
2013-12-10 19:09:56 ee89ba2e-087e-46e2-9654-059283****df Certify ‘testuser@****.onmicrosoft.com’ ‘Success’ c***81be-1524-46de-b5ae-f651***6cae4 – ‘MSIPC;version=1.0.621.176;AppName=OUTLOOK.EXE;AppVersion=15.0.4551.1004;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=amd64′ 10*.20*.*00.*6
2013-12-10 19:10:03 ***fab13-b3d7-40f1-9fd8-71a1390dc6a2 AcquireLicense ‘testuser@****.onmicrosoft.com’ ‘Success’ 0e6bba***9e27-4174-9748-***d2ee82aaf {220c***4-227d-461c-857f-57d****cfb88} ‘MSIPC;version=1.0.621.176;AppName=OUTLOOK.EXE;AppVersion=15.0.4551.1004;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=amd64′ 10*.20*.*00.*6
Lots of good information about what kind of access is going on. Additionally, I can open my storage account and find all my files there for reference as well:
A couple of other strategies/considerations from Microsoft:
Because the logs are not necessarily chronological but the majority of them are written within 15 minutes of the request, when you identify the logs that you want by using their timestamp , add 15 minutes to the time that you are interested in. Then download these logs. This strategy should ensure that you get almost all logs.
One other thing to remember is that the timestamp on each log record is the local time of the RMS server that processed the request. Because RMS runs on multiple servers across multiple data center, sometimes the logs might seem to be out of sequence, even when they are sorted by their timestamp. However, the different is small and usually within a minute. In most cases, this is not an issue that would be a problem for log analysis.
Auditing and logging should be a key component to any security solution. As referenced at the beginning, auditing is not something that is enabled by default, so be proactive and turn this on now so you don’t find yourself needing reports on information you haven’t been collecting!
Excluding personalized pieces, the technical information around enabling and working with logging and analyzing RMS AAD usage can all be found here: http://technet.microsoft.com/en-us/library/dn529121.aspx
Source: http://office365tipoftheday.azurewebsites.net/?p=2291
