You can configure the Azure Rights Management service to generate and give you a log of every request that the Azure Rights Management service fulfils for your tenant as soon as it happens.
This information is very useful for a variety of reasons:
Examples of insight you can gain are: who is accessing your RMS-protected assets, what are they accessing, from what devices, from where, are they getting a satisfactory experience, who all has read a given document etc.
You know your employees best and are uniquely qualified to identify an abuse pattern. As an example, your administrators may want to be alerted if there is a spike in accesses to your assets during off hours (insider trying to steal a bunch of documents?), or if the same user accesses from two different IP addresses within 15 minutes (potential password compromise?).
With the Azure Rights Management service's architecture, your documents can flow any way you want (email, cloud storage such as Dropbox, USB, etc.) but recipients must get a license from the Azure Rights Management service to open and consume those documents. Therefore the Azure Rights Management service's logs are a definitive source of information for forensics, as long as your assets are protected with the Azure Rights Management service.
This document provides information about the logging capability of the Azure Rights Management service and thus about monitoring and controlling its usage. More particularly, it provided an in-depth description of this capability, how to enable it in your environment and your related subscription of the Microsoft Rights Management cloud-hosted service along with the standard format used for the log files.
Furthermore, by following the steps outlined in this document you should be able to successfully prepare your environment to leverage the logging capability, enable it and efficiently monitor the usage of the service over the time, and consequently start using the Azure Rights Management service within your organization to create and consume protected content in compliance with your own security and IT policies in place.
Note The logging capability is available to you whether you let Microsoft generate your key (the default) or you bring your own key (BYOK) (see whitepaper Bring Your Own Key with Azure Rights Management). But when you bring your own key, the Azure Rights Management service also logs every usage of your key in addition to front-end request logs. This allows you to monitor in near real-time how your key is being used.
This document doesn't offer a full description of the Microsoft Rights Management services offerings. It rather simply focusses on key aspects in the context of this paper that aims at providing the readers an understanding on how to leverage and enable logging capability in your environment and your related subscription of the Microsoft Rights Management cloud-hosted service.
Note For an overview of the NEW Microsoft Rights Management services offerings, see the whitepaper Microsoft Rights Management services, the online documentation, the series of whitepapers on RMS to which the current document belong as well as the posts on the RMS Team blog.
To cover the aforementioned objectives, this document is organized by themes, which are covered in the following sections:
This document is intended for IT professionals and system architects who are interested in understanding the logging capability of the Azure Rights Management service and, thus monitoring and controlling its usage.
Opting in for logs is completely optional. All functionality of the Azure Rights Management service will work the same way whether or not you opt in to receive logs.
The Azure Rights Management service provides you logs for no extra charge. You must provide an Azure storage account to receive logs in, and you will be billed for the storage used.
To exercise the Usage Logging feature, the pre-requisites are as follows:
Pre-requisite | Description |
An IT-managed Azure Rights Management service subscription | You must have an Azure Rights Management service subscription managed by your organization. Organizations that use the free 'RMS for Individuals' offer cannot get logs. |
An Azure subscription | You must have a subscription to Azure and sufficient Azure storage to store your logs. |
The rest of this document will guide you through the entire process to benefit from such a capability.
As previously outlined, the Azure Rights Management service writes logs to an Azure storage account that you provide. The rest of this section steps you through how to create such an account.
The steps below assumes you already have an Azure account. For testing purpose, you can subscribe for a free Azure 1-month trial.
We support individual accounts, but recommend organizational accounts.
We recommend you set up a dedicated storage account for the Azure Rights Management service's logs. You will need to share the storage account keys with the Azure Rights Management service, and potentially with other staff in your organization that report on your logs.
To set up an Azure storage, proceed with the following steps:
Wait for Azure to create your account. Once complete, you will see a status of Online as shown next.
The configuration leverages the cmdlets of the Azure Rights Management administration module for Windows PowerShell. Most Azure Rights Management service's administrative tasks need this package.
Note Windows PowerShell
is a task-based command-line shell and scripting language that is designed for system/service administration and automation. It uses administrative tasks called cmdlets. Each cmdlet has required and optional arguments, called parameters, that identify which objects to act on or control how the cmdlet performs its task. You can combine cmdlets in scripts to perform complex functions that give you more control and help you automate the administration of Windows, applications and online services in the Cloud. It has become a common way to manage the latest generation of Microsoft products and services.
A Windows PowerShell "module" is a package that contains Windows PowerShell commands, cmdlets, providers, functions, variables, and aliases. The Azure Rights Management Administration Module for Windows PowerShell is a separate installation package which includes cmdlets specifically designed for the Azure Rights Management service tenant-based administration.
For more information about Windows PowerShell, please see the Windows PowerShell Web site, the Windows PowerShell online help, and the Windows PowerShell Weblog
Windows PowerShell Software Development Kit (SDK) that includes a programmer's guide along with a full reference.
This section walks you through the installation of the Microsoft Rights Management administration module.
Note For additional information, see the Microsoft TechNet article Install Windows PowerShell for rights management.
The Microsoft Rights Management administration module requires the Microsoft Online Services Sign-In Assistant (MOS SIA) 7.0, which is 7.250.4551.0 as of this writing. So we will install it manually.
Note The Microsoft Online Services Sign-In Assistant (MOS SIA) 7.0 provides end user sign-in capabilities to Microsoft Online Services, such Office 365 and the Azure Rights Management service. In the context of this paper, the MOS SIA is used to authenticate users to these services through a set of dynamic link library files (DLLs) and a Windows service as described in the community article Description of Microsoft Online Services Sign-In Assistant (MOS SIA).
To install the Microsoft Online Sign-In Assistant (MOS SIA) 7.0, proceed with the following steps:
To connect Windows PowerShell to the Azure Rights Management service, proceed with the following steps:
The Microsoft Rights Management administration module for Windows PowerShell provides a set of Windows PowerShell cmdlets that provide administrative (advanced) capabilities for the Azure Rights Management service. These cmdlets will be used later in this document with for the logging capability. More especially, in the context of this document, the cmdlets relevant to the logging capability are the following ones:
Detailed help is available from an elevated Windows PowerShell command prompt by executing these commands with the -? option.
To configure the Azure Rights Management service to log to the Azure storage account, proceed with the following steps:
PS C:\Windows\system32> Import-Module AADRM
PS C:\Windows\system32> Connect-AadrmService -verbose
You will be prompted for your credentials.
Username: philber@demorms.onmicrosoft.com
Password: ****************
PS C:\Windows\system32> $accesskey = Convert-SecureString " wUjKVV14XXUCrdpuLsIa8yQ5IgUmLSOLmlgS/CcHNZXiurEORjTItdtPf4OpCaIwGNyijjMPxvDEOG21HRKR7A==" –asplaintext -force
PS C:\Windows\System32> Set-AadrmUsageLogStorageAccount -StorageAccount corpcontoso -AccessKey $accesskey
corpcontoso was set as the storage account for the usage log feature for the Rights management service.
PS C:\Windows\system32>
PS C:\Windows\system32> Enable-AadrmUsageLogFeature
The usage log feature is enabled for the Rights management service.
PS C:\Windows\system32>
From this point onwards the Azure Rights Management service will log all requests served on behalf of your tenant to your storage account. Logs before this point are not available.
The Azure Rights Management service writes logs to your Azure storage account as a series of blobs. Each blob contains one or more log records, in W3C Extended Log (Weblog) format. The blob names are numbers, in the order they were created.
Section § Understanding the log format describes the log format in detail.
Logs may take up to a few minutes to show up in your storage account after the Azure Rights Management service serves a request for your tenant. 99.9% of logs should appear in your account within 15 minutes after the request is served.
You can retrieve these logs in two ways:
The Get-AadrmUsageLog cmdlet lets you download logs to your computer. This cmdlet downloads each blob as a file to the location you specify. You may analyze these files locally or import them into a database or Hadoop storage to do serious crunching.
Example 1: still from the previous elevated Windows PowerShell command prompt, run the following command to download ALL available logs from your storage account to your C:\Logs folder:
PS C:\Windows\system32> Get-AadrmUsageLog –Path "C:\Logs"
1527
PS C:\Windows\system32>
Example 2: still from the previous elevated Windows PowerShell command prompt, run the following command to download a specific range of blob:
PS C:\Windows\system32> Get-AadrmUsageLog –Path "C:\Logs" –FromCounter 1024 –ToCounter 2047
2047
PS C:\Windows\system32>
The cmdlet displays on the console the name of the last blob it downloaded. You can assign this to a variable as shown next. This allows you to run Get-AadrmUsageLog in a loop or a scheduled job, downloading only the incremental logs each time.
PS C:\Windows\system32> $LastBlobName = Get-AadrmUsageLog –Path "C:\Logs"
1527
PS C:\Windows\system32> $LastBlobName
1527
PS C:\Windows\system32>
To download blobs starting from the last downloaded one to the last available on, run the following command.
PS C:\Windows\system32> $LastBlobName = Get-AadrmUsageLog –Path "C:\Logs" –FromCounter $LastBlobName –ToCounter (Get-AadrmUsageLogLastCounterValue)
In some situations you may want more flexibility than Get-AadrmUsageLog provides. E.g. you may need to delegate the downloading of logs to a person or process that cannot have your Azure Rights Management service's administrative credentials. Or you may want to poll for logs in realtime in order to monitor abuse.
In such situations, you can retrieve the logs using the Azure Storage SDK directly.
The storage account you created for logs is like a mailbox. It supports reading directly from the storage account, but is not optimized for this. For best performance and cost we recommend you download the logs to destination appropriate for your application use case, such as a local folder, a database, or a Map/Reduce repository.
Here is an example of how to aggregate all your downloaded log files into a CSV format using the Microsoft Log Parser utility, which is a tool to convert between various well-known log formats. The same tool can be used to convert to SYSLOG format, or import into a database:
C:\users\joesmith\logs> logparser –i:w3c –o:csv "SELECT * INTO AllLogs.csv FROM *.log"
Statistics:
-----------
Elements processed: 36
Elements output: 36
Execution time: 0.08 seconds
C:\users\joesmith\logs>
To interpret the logs, see Section § Understanding the log format.
Should you for any reason not want logs any more, run the Disable-AadrmUsageLogFeature cmdlet from the elevated Windows PowerShell command prompt:
PS C:\Windows\System32> Disable-AadrmUsageLogFeature
The usage log feature is disbled for the Rights management service.
PS C:\Windows\System32>
The Azure Rights Management service stops writing logs to your account immediately. However it retains your storage account information. So you can resume logging again. To resume, just run the cmdlet Enable-AadrmUsageLogFeature as illustrated before.
PS C:\Windows\system32> Enable-AadrmUsageLogFeature
The usage log feature is enabled for the Rights management service.
PS C:\Windows\system32>
If you are not sure what state your logging is in, use the Get-AadrmUsageLogFeature cmdlet. In the following example, the return value of "True" means logging is currently enabled.
PS C:\Windows\system32> Get-AadrmUsageLogFeature
True
PS C:\Windows\system32>
You manage your storage account directly. You can leave your logs there for as long as you wish. Or you may delete the logs after you download them. Or you can prune selectively. The Azure Rights Management service does not read the blobs back, so what you do with your logs will not interfere with the Azure Rights Management service.
The one exception to the previous statement is the blob named "metadata" in the container "rms-metadata". Do not modify or delete this blob. The Azure Rights Management service uses this blob to keep track of the last blob number it wrote. If you accidentally delete the metadata blob, Azure RMS will start a new container for logs, with a blob number starting from 1. All future downloads using the Get-AadrmUsageLog cmdlet will download logs from the new container only. The logs in the previous container will be preserved but orphaned. You can download previous logs with the Azure storage SDK, but the Get-AadrmUsageLog cmdlet will have no knowledge of it.
You will be billed for space used for as long as you keep your logs in Azure storage.
You can also delegate the management function to a vendor by sharing your storage account name and access key.
If you change the vendor that processes your logs, or if you suspect that your storage account key was breached, then you must regenerate your storage account keys. In order to prevent interruption in service, Windows Azure storage gives you two keys, a primary and a secondary key. Regenerate the key that you are NOT using, e.g. if you configured the Azure Rights Management service to use the primary access key, then regenerate the secondary access key by clicking regenerate.
Once regenerated, configure the Azure Rights Management service to use the new key by running the cmdlet Set-AadrmUsageLogConfig.
PS C:\Windows\system32> $accesskey = Convert-SecureString " wUjKVV14XXUCrdpuLsIa8yQ5IgUmLSOLmlgS/CcHNZXiurEORjTItdtPf4OpCaIwGNyijjMPxvDEOG21HRKR7A==" –asplaintext -force
PS C:\Windows\System32> Set-AadrmUsageLogConfig -StorageAccount corpcontoso -AccessKey $accesskey
corpcontoso was set as the storage account for the usage log feature for the Rights management service.
PS C:\Windows\system32>
Now you can regenerate the other access key.
To switch to a different storage account, run Set-AadrmUsageLogConfig with the new storage account and key. Do this only if really necessary. Doing so will cause your new logs to go to the new storage account. The previous logs will stay in the previous storage account. The Get-AadrmUsageLog cmdlet (and likely most other applications) will know of the latest storage account and logs only.
You can delegate the processing of your RMS logs to a vendor by sharing your storage account name and access key. Since they will not have your Azure Rights Management service administrator credentials, they cannot use the Get-AadrmUsageLog cmdlet to download logs. Instead, they must retrieve the logs using the Windows Azure Storage SDK or other relevant tooling.
It is safe to share your storage account name and access key with your vendor as long as that storage account is dedicated to your logs. Access to that key does not grant access to any of your other storage accounts nor to your Azure Rights Management service tenant itself.
This section explains the format of the logs.
The first time the Azure Rights Management service writes logs to your storage account, it creates two containers.
Over time the Azure Rights Management service may create additional containers of the form Rms-logs-<guid>. Specifically, if the container Rms-metadata is accidentally deleted or corrupted, the Azure Rights Management service resets its contents, creates a new Rms-logs-<guid> container to write all further logs to. Previous log containers are left untouched but they are orphaned from the Azure Rights Management service's perspective.
The Azure Rights Management service writes the logs as a series of blobs. Each blob contains one or more log records, in extended W3C log format as previously outlined.
The name of each blob is a number. Within each log container the first blob is named "000000001". Each blob is named sequentially in the order it was created. Each blob contains one or more log records. Each log record has a UTC time, which indicates when the corresponding request was served by the Azure Rights Management service.
The Azure Rights Management service's logging system is optimized to get log records to you efficiently, rather than in strict sequential order. The order of blobs, as well as the order of log records within a blob, may be out of chronological sequence. The only reason the blobs are named sequentially is to enable you to download them efficiently incrementally.
Let's illustrate this with some examples:
Before you analyze the logs, we recommend that you download and import the logs into a repository where you can sort the logs based on timestamp. You can download using the Get-AadrmUsageLog cmdlet or on your own using the Azure Storage SDK.
If the logs are not chronological, you may be wondering how to find out if you have received all logs until a certain point. The Azure Rights Management service will write 99.9% of logs within 15 minutes of the request happening. So in practice if you collect all logs until 15 minutes past the point in time you are interested in, you should receive almost all logs.
One other caveat you should be aware of is that the timestamp on each log record is the local time of the server that processed the request. Because the Azure Rights Management service runs on multiple servers across multiple data centers, sometimes the logs may seem out of sequence even when sorted by timestamp. They are close though, within ±1min. This is typically not an issue for most real-world use cases for log analysis.
Each blob is in W3C Extended log format. Here is an example of a log file.
#Software: RMS
#Version: 1.0
#Fields: date time row-id request-type user-id result correlation-id content-id c-info c-ip
2013-09-19 13:46:44 0d07036b-c66c-4e92-b887-f59ecd61dc96 AcquireLicense 'janet@corp-contoso.com' 'Success' ad18e935-bcf9-4b51-9d34-cf3391c451ef {9312A0DF-DA57-4854-9160-603A1ED06CB3} 'MSIPC;version=1.0.622.36;AppName=WINWORD.EXE;AppVersion=15.0.4535.1000;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=x86' 94.245.87.113
As you can see, it starts with the following two lines.
#Software: RMS
#Version: 1.0
The first line identifies that these are the Azure Rights Management service's logs. The second line identifies that the rest of the blob follows the version 1.0 specification (as depicted as part of this document). Applications that parse these logs are advised to verify these two lines before parsing the rest.
The third line enumerates a list of field names, separated by tabs.
#Fields: date time row-id request-type user-id result correlation-id content-id c-info c-ip
Each of the subsequent lines is a log record. The values of the fields are in the same order as the definition line above, and are separated by tabs.
The following table provides the field definitions.
Field name |
W3C data type |
Description |
Example value |
date |
Date |
UTC Date when the request was served. The source is the local clock on the server that served the request. |
2013-09-19 |
time |
Time |
UTC Time in 24H format when the request was served. The source is the local clock on the server that served the request. |
13:46:44 |
row-id |
Text |
Unique GUID for this log record. This is useful for provenance when you aggregate logs or copy logs into another format. |
0d07036b-c66c-4e92-b887-f59ecd61dc96 |
request-type |
Name |
Name of the RMS API that was requested |
AcquireLicense |
user-id |
String |
The user who made the request. The value is enclosed in single quotes. Some request types are anonymous, in which case this field is ''. |
'janet@corp-contoso.com' |
result |
String |
'Success' if the request was served successfully. The error type in single quotes if the request failed. |
'Success' |
correlation-id |
Text |
GUID that is common between RMS client log and server log for a given request. This helps in troubleshooting client issues. |
ad18e935-bcf9-4b51-9d34-cf3391c451ef |
content-id |
Text |
GUID, enclosed in curly braces, that identifies the protected content e.g. a document. This field has a value only if request-type is AcquireLicense, it is blank for all other request types. |
{9312A0DF-DA57-4854-9160-603A1ED06CB3} |
c-info |
String |
Information about the client platform making the request. The specific string varies depending on the application, OS, browser. |
'MSIPC;version=1.0.622.36;AppName=WINWORD.EXE; AppVersion=15.0.4535.1000;AppArch=x86;OSName=Windows;OSVersion=6.2.9200;OSArch=x86' |
c-ip |
Address |
IP address of the client making the request |
94.245.87.113 |
The following values of user-id are special and do not map to a real user.
The number of request types in Azure Rights Management is long and growing. Here are some of the common request types.
Field name |
Description |
AcquireLicense |
Client is requesting a license for a specific piece of content, from a Windows computer. |
FECreateEndUserLicenseV1 |
This is similar to the AcquireLicence request. This endpoint is for mobile clients. |
Certify |
Client is requesting a certificate (which is later used to get a license) from a Windows computer. |
GetClientLicensorCert |
Client is requesting a publishing certificate (which is later used to protect content) from a Windows computer. |
FECreatePublishingLicenseV1 |
This is the same as the previous two combined, from mobile clients. |
FindServiceLocationsForUser |
This is sometimes anonymous, and sometimes with authenticated. This is an innocuous request that queries for the URLs to certify and acquire license from. |
Decrypt |
You will see this only if you brought in your own key (BYOK, see whitepaper Bring Your Own Key with Azure Rights Management). The Azure Rights Management service logs this when your key is used for decrypt – typically once per AcquireLicense and Certify. |
Sign |
You will see this only if you brought in your own key (BYOK). RMS logs this when your key is used for signing – typically once per one time per AcquireLicence (or FECreateEndUserLicenseV1), Certify, and GetClientLicensorCert (or FECreatePublishingLicenseV1). |