Azure Information Protection General Troubleshooting

Posted on 1 CommentPosted in aadrm, AIP, Azure Information Protection, encryption, IAmMEC, Office 365, rms

Azure Information Protection (AIP) is the new name, and new features for Azure Rights Management. Azure Information Protection allows a company to create a series of labels to apply to documents and to have those documents tags and labelled. For example a watermark or header is easy to set in the Azure Information Protection management blade in portal.azure.com.

In fact its so easy to turn on I did just that. The actual work and business consulting with Azure Information Protection is the why and business reasons for using it rather than the technical steps to enable it.

So once I enabled it and the client installed I found that I had a banner toolbar in Office applications as shown:

image

Clicking any of the labels will perform the default function of the product. These can be modified in the Azure Portal as shown:

image

image

The above two graphics show one example label (Confidential) that has had a sub label added (called NBConsult UK). The larger image above shows the details for this “NBConsult UK” label. In the properties blade for the label you can see I have turned on a template from RMS.

Once the changes are made and saved, you can publish the changes. Clients will pick up these changes on restarting the client application.

image

And then started my issues and the steps to troubleshoot this. First I got the following prompt twice:

image

Followed by:

image

And so I was finding my documents did not get the RMS based labels applied.

Reasons why this might be the case can be checked using the RMS tool in the Office application. So I tried to protect the document manually via File > Info tab:

image

This worked – I had the rights to use the template in the application – just AIP could not apply the template via the AIP tool.

To fix this I ran the Azure Information Protection (AIP) diagnostics tool. To get this click the AIP lock icon and choose Help and Feedback from the menu:

image

From this a popup appears:

image

And from this choose Run diagnostics:

image

Let the tool complete. I got the following errors before the application failed (crashed) and then did not complete again if left it again

image and then image

To get around this issue, as the reset option to fix the AIP application in the diagnostics tool was not available due to the application crash, I followed the steps in http://social.technet.microsoft.com/wiki/contents/articles/19251.ad-rms-troubleshooting-reset-the-client-msipc.aspx to bootstrap the client manually. If the AIP diag client completes, fix the listed issue or choose Reset in the client.

Once I had deleted the files and related registry keys mentioned in the above website I could restart any Office application. The RMS certs, keys and settings where downloaded to the client again and the AIP client was able to protect a document where as before it was not:

image

image

Managing Azure Active Directory Rights Management

Posted on Leave a commentPosted in 2013, aadrm, dirsync, encryption, IAmMEC, journal, journaling, licence, mcm, mcsm, MVP, Office 365, rms, transport agent

This article is the third in a series of posts looking at Microsoft’s new Rights Management product set. In the previous post we looked at turning on the feature in Office 365 and in this post we will look at how to manage the service in the cloud.

In this series of articles we will look at the following:

The items above will get lit up as the articles are released – so check back or leave a comment to the first post in the series and I will let you know when new content is added.

Once you have signed up for the Azure Active Directory Rights Management (AADRM) Service there are a few things that you need to manage. These are:

  • The service itself
  • Users who are allowed to create RMS protected content
  • Enable and configure Super User rights if required.

Managing AADRM

There is not a lot to do in the Office 365 admin web pages with regard to the management of the service apart from enabling it, which we covered in the previous post and disabling it. Disabling the service involves the same steps as enabling it – you just click the big deactivate button!

AADRM can be further managed with PowerShell though. There are lots of blog posts on connecting to Office 365 using PowerShell, and some of those include the cmdlets to connect to Exchange Online etc. as well. The code below adds to this, and loads the AADRM module and connects to AADRM service in the cloud.

$cred = Get-Credential

write-host "Username: " $cred.username

Connect-MsolService -Credential $cred

Write-Host "...connected to Office 365 Windows Azure Active Directory"

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection

$importresults = Import-PSSession $s -Verbose

Write-Host "...connected to Exchange Online"

Import-Module AADRM

Connect-AadrmService -Verbose -Credential $cred

If you save the above PowerShell code as a text file with a .ps1 extension then you can run the script and easily connect to Office 365 with the credentials you enter. Then connect to Exchange Online with the same set of credentials and finally to AADRM with, of course, the same credentials. This allows you to manages users, email and security from a single session.

To get the AADRM PowerShell module on your computer (so that Import-Module AADRM works) you need to download the Rights Management PowerShell administration module from http://go.microsoft.com/fwlink/?LinkId=257721 and then install it.

To install you need to have already installed the Microsoft Online Services Sign-In Assistant 7.0 and PowerShell 2.0. The PowerShell config file needs some settings adding to it, though I found on my Windows 8 PC that these had already been done. See the instructions at http://technet.microsoft.com/en-us/library/jj585012.aspx for this change to the config file.

  1. Run a PowerShell session and load the module with
    1. Import-Module AADRM
    2. Connect-AadrmService -Verbose
  2. Login when prompted with a user with Global Admin rights in Office 365.
  3. Or, use the script above to do Office 365, Exchange Online and AADRM in a single console.
  4. Run Get-Aadrm to check that the service is enabled

Enabling Super User Rights

Super Users in RMS are accounts that have the ability to decrypt any content protected with that RMS system. You do not need Super User rights to use RMS, nor do you need anyone who has Super User rights to use the product. But there are times when it might be required. One example would be during a discovery or compliance process. At this time it might be required that someone is able to open any RMS protected document to look for hits on the compliance issue in question. Super User gives that right, but would be needed just for the duration of the task that requires these rights. Rights to be Super User would be granted as needed and very importantly removed as needed.

Another example for the use of Super User is when a process needs to see content in its unprotected form. The common use case for this is Exchange Server and its transport decryption process. In Exchange Server you have agents that run against each message looking for something and then acting if that something is found. For example you would not want an virus to bypass the built in AV features of Exchange Server 2013 by protecting it with RMS! Or if you had a disclaimer transport rule or agent, you would not want the disclaimer or DLP feature to not see the content and act upon it because the content was encrypted. The same goes for journaling and the ability to journal a clear text copy of the message as well as the encrypted one if you wish.

To do all this in Exchange Server, the RMS Super User feature needs to be enabled and we will come back in a later post on the specifics of doing that for Exchange, but first we need to enable it in AARMS and set the users who will be Super Users and then, when we are finished with whatever required Super User, we need to turn it off again.

The Rights Management super users group is a special group that has full control over all rights-protected content managed by the Rights Management service. Its members are granted full owner rights in all use licenses that are issued by the subscriber organization for which the super users group is configured. This means that members of this group can decrypt any rights-protected content file and remove rights-protection from it for content previously protected within that organization.

By default, the super users feature is not enabled and no groups or users are assigned membership to it. To turn on the feature run Enable-AadrmSuperUserFeature from the AADRM PowerShell console. The opposite cmdlets exists to turn the feature off again – Disable-AadrmSuperUserFeature!

Once it is enabled you can set Office 365 users as Super Users. To do this run Add-AadrmSuperUser –EmailAddress user@domain.com where the user is either a cloud only Office 365 account or one that you have pushed to Office 365 using DirSync from your on-premises Active Directory. You can add more than one user, each user is added as a separate running of the cmdlets.

To see your list of Super Users, run Get-AadrmSuperUser. To remove users either take them out one by one (Remove-AadrmSuperUser –EmailAddress user@tenant.onmicrosoft.com) or just turn off the Super User feature with Disable-AadrmSuperUserFeature.

Adding AADRM Licences to Users

Once you have AADRM activated you can give your users the rights to create protected content. This is done in the licencing page of the Office 365 web admin portal or via PowerShell. The steps for adding user licences in the shell are discussed at http://c7solutions.com/2011/07/assign-specific-licences-in-office-365-html. That article was written some time ago, so the following are the changes for AADRM:

  • The SkuPartNumber for AADRM is RIGHTSMANAGEMENT_ADHOC
  • The Service Plan for the AADRM SKU is RMS_S_ADHOC

Ensuring Email Delivery Security with Exchange 2013

Posted on 4 CommentsPosted in 2007, 2010, 2013, encryption, exchange, IAmMEC, TLS, transport

To force Exchange 2013 to guarantee the secure delivery of a message can be done a few different ways. In this version of the product and in previous versions it was possible to create a send connector for a given domain and enable Mutual TLS on the connector. Then all messages to the domain(s) that this connector serviced would need to travel over a TLS connection where the certificate at both ends was completely valid (i.e. valid regards the date, had the correct subject or SAN for the domain, was issued by a trusted certificate authority etc.). In previous versions (2007 to 2010 again) it was possible to enable Domain Secure and add another level of checks to the Mutual TLS session. Domain Secure does not work in Exchange 2013.

And great though these methods of transport security are, they are limited in that they are difficult to set up (require good knowledge of certificates) and needs to be properly configured at both ends of the connection. They are also limited in that they will only secure email to the selected domains. If you need to send a “top secret” email to someone, you don’t really want to have to configure a connector at both ends and force all email for that domain down the same path.

So, in Exchange 2013 you can create a transport rule to force the connection to use TLS, and if TLS fails then have the message queue on the sender until it retries and eventually expires. If TLS is never available, the message never goes out of Exchange – or so it would be if all you read was the description in the documentation!

The RouteMessageOutboundRequireTLS transport rule action (or the Secure the message with > TLS encryption option in the ECP transport rules wizard) allows you to craft a rule for any condition (for example the subject or body contains any of these words: top secret) which will require the email to use an encrypted session for the delivery outside of Exchange Server. Note that for this to work the TLS session does not need to be protected by a given certificate or valid etc., it just needs the receiving SMTP Server to offer STARTTLS and for the encryption to work.

And it needs a source server for sending the message in every Active Directory site within the organization. Currently (as of CU2 for Exchange 2013) if you send a message from a site that does not contain a send connector that can handle the message to the internet then Exchange will pass it to a site that can, but the source transport server will now not enforce the TLS requirement and will send the message unprotected if STARTTLS is not offered.

So if you want to guarantee the use of TLS for certain types of message use the RouteMessageOutboundRequireTLS transport rule condition and ensure that you do not need to do cross site delivery of messages to reach a send connector source server to delivery the message to the internet.