Category Archives: Azure Information Protection

Azure Advent Calendar 2019 – Azure Information Protection

Leave a reply

Today is 18th December and my turn to being part of the awesome Azure Advent Calendar. Thanks to Gregor Suttie (@gregor_suttie) and Richard Hooper (@Pixel_Robots) for this great initiative.

In today’s video, linked below, I’m speaking about Azure Information Protection (https://docs.microsoft.com/en-us/azure/information-protection/). I tried to keep the video under 30 minutes, but there is so much to talk about that I ended up doing a full 45 minute session. If you are new to Azure Information Protection, this will hopefully be a good start. If you already know a thing or two about AIP and RMS, you might pick up some tips and pointers as well. I will also go into the new functionality of Unifying Labeling, and look at some of the client experiences.

So with that, here is my contribution for Azure Advent Calendar 2019:

Protecting Norwegian National ID Number with Azure Information Protection and RMS

2 Replies

In Norway we have a National Identification Number which is an 11-digit personal identifier, which also is referred to a Birth Number as this is given to every Norwegian borned at birth.

The number consists of:

  • 6 first digits are birth date in the form of: ddmmyy
  • 3 next digits are personal, with the last of those 3 indicating whether you are male (odd number) or female (even number)
  • The last 2 digits are control digits, based on modulus functions on the first digits

(Source: http://www.skatteetaten.no/en/person/National-Registry/Birth-and-name-selection/Children-born-in-Norway/National-ID-number/)

The special thing about Norwegian National ID Numbers are that they are not only used for personal identification, but also in some official scenarios is used for source of authentication. This makes this ID number highly sensitive, and should not be shared around in for example documents and emails.

In this blog post I will look at how Azure Information Protection can automatically detect and classifiy documents that contains the Norwegian National ID Number, and more over how we can use Azure Rights Management Services (RMS) to automatically apply a RMS template which encrypts and sets permissions for these classified documents.

I will show this step by step, so read on for details.

Activate Azure Rights Management Services and Azure Information Protection for your Azure AD

The requirement for setting this up is that you have a Tenant with an Azure AD Directory, and licensed with EMS Suite (E3 or E5), Secure Productive Enterprise (SCE) or Azure Information Protection P1 or P2 licenses. You will need the EMS E5/AIP P2 if you want to be able to automatically classify and label documents, as E3/P1 only enables users for manual classification and labeling. You can get EMS E5 trial licenses if needed.

To active Azure RMS, if you havent already done this, go to: https://account.activedirectory.windowsazure.com/RmsOnline/Manage.aspx

If you get this message you are OK to proceed to next step:

image

Next, in a new browser window, sign in to the Azure portal as a global admin for your tenant.

On the hub menu, click New, and then select Security + Identity. In the Security + Identify blade, select Azure Information Protection. In the Azure Information Protection blade, click Create. This will enable Azure Information Protection and make it accessible for your configured services later. If you selected to pin the blade, you will have easy access for configuring Azure Information Protection later:

image

Configure Classification and Labeling

In this step we will configure the classification and labeling for the Norwegian National ID Number.

First, when I start the default configuration of Azure Information Protection, I will se these built-in classification labels:

image

These classification labels should be sufficient for a lot of protection scenarios, but in this case I will add a new label for protecting restricted content like the Norwegian National ID Number. I select to add a new label, as shown below:

image

I give the new label the name Restricted, and provide a custom tooltip for the users to see. I can select another color if I want, and for now I don’t want to add an Azure RMS template for protection.

Further down, I add visual markings, by providing a Header text:

image

And a watermark:

image

Next I can specify conditions for automatically applying a label. This is where I will check for any Norwegian National ID Numbers. First I add the Condition:

image

Then I select Custom type of condition, because the built-in ones does not contain the Norwegian ID number. Under Custom I specify a name for the condition, and select to match based on a regular expression. See explanation below. I can also match on case sensitivity (if letters) and number of occurances if I want.

image

So, the main part here is the Regular Expression (RegEx) that will discover if there could be a possible match on a Birth Number/Norwegian National ID Number.

I will not dive into details on Regular Expressions here on my blog, but in short the following expression will match if the first 6 digits are a valid date. For example 31 days in the months Jan, Mar, May, July; Aug, Oct and Dec, and 30 days in the rest. In addition, this will not check for leap years, so will accept 29 days for each Feb to simplify. The last 5 digits are accepted if they are 0-9.

(0[1-9]|[1-2][0-9]|31(?!(?:0[2469]|11))|30(?!02))(0[1-9]|1[0-2])\d{7}

This expression could be even better, and I might look into that later:

  • If the 3 digits after the date were checked to be in the right group based on birth year
  • If the last 2 digits were in fact modulus calculating on the previous

But for now this should be sufficient.

After adding that condition, I specify a tooltip for the end users:

image

All that is left now is to save and publish my new classification label:

image

Download and Install the Azure Information Protection Client

Next step is to Install the Azure Information Protection client on a PC that has Office installed. Download the client from from the Microsoft download center, https://www.microsoft.com/en-us/download/details.aspx?id=53018.

Run AzInfoProtection.exe and follow the prompts to install the client. As we have configured the tenant with the default and customized label, it doesnt matter if you install the demo labels as the tenant settings will override.

After installing the client and starting any Office program we will se the toolbar as shown below:

image

Testing Automatic Classification of National ID Number

If I open a new document in Word and type in as below for an example valid National ID Number:

image

I then have to save the document, because the validation of conditions for classification labels happens at save time.

And as expected, the document has now been automatically classified as Restricted, with the explanation that a Norwegian National ID Number has been detected:

image

I also see the watermark and the header text for the document:

image

At this point we are able to automatically classify the document as restricted and sensitive, but the document can still be shared unencrypted if the user wants to do that.

In the next step we will see how we can configure automatic data protection for this classification label.

Configure Data Protection

If we want to configure automatic data protection for classified documents I will need to either use an existing or create a new Azure RMS Template. In this case I will create a new template. This must, for now, be done in the old Azure Portal at manage.windowsazure.com, and under your Azure Active Directory and Rights Management settings.

image

When you enable Azure Rights Management for your tenant you will have two default RMS templates specified:

  • <organization name> – Confidential
  • <organization name> – Confidential View Only

I will now create a new RMS template for my organization, which I will use for protecting documents that are classified as Restricted. First I specify language, name and description for the new template:

image

After creating the RMS template I can now configure rights, scope and optional configurations.

image

Under Rights I have added a couple of groups from my Organization where I configure a Rights role of Viewer:

image

The Viewer Role has the following custom rights, which suits my scenario where I want to restrict sharing for Restricted Sensitive Information.

image

I can define the scope of the RMS template, which defines who in my organization can apply this template. I want everybody to be able to use this template, so I will not change any scoping settings now:

image

At the configuration section I can choose to Publish the template, and change settings for additional languages, content expiration and offline access. I have left the default settings on and publish the RMS template as ready to use:

image

With the new RMS template ready, I can now go back to Azure Information Protection and Configure the Protection settings for my “Restricted” classification label. I select my new RMS template from the dropdown menu:

image

After that I hit Save, and then Publish the policy:

image

I can now see that my Restricted classification label both have Marking, Protection and Conditions defined:

image

Testing Automatic Protection

We will now test this in a new Word document. Once again I type a National ID Number and Save the document. And now I see that the document both is automatically classified and protected:

image

As I am the owner of the document, I can share it internally to any user in my organization, but they will be prohibited to do any operations besides viewing the document.

And if I share the document to an external user outside my organization, they will be prohibited to view the document and contents as well, as they are not able to open and view the document without an Azure AD user from my organization:

image

If I wanted to restrict my users from even sharing it internally, I would need to configure an Office 365 Data Loss Prevention (DLP) Policy, which can apply to Exchange Online, SharePoint Online and/or OneDrive for Business, and look for Norwegian National ID Number there. But that would be a topic for another blog post!

Classifying and Protecting Outlook E-mail

Does this only apply to Office documents? No, when you install the Azure Information Protection client you get the opportunity to classify and protect e-mails sent with the Outlook client as well.

When I send an e-mail message that contains a Norwegian National ID Number and after I hit the Send button, the automatic classification and protection will be applied to the e-mail:

image

The external receipient of the e-mail will se this message, and will not be able to see the e-mail content:

image

Conclusion

In this blog post I have shown how you can use Azure Information Protection (AIP) to classify Office documents and Outlook e-mails and how you can use conditions to automatic apply that classification based on for example a Norwegian National ID Number detection with the use of a regular expression.

In addition I have shown how you can use Azure RMS and a template to automatically encrypt that document and set the permissions for the users in my organization that only allows viewing.

How to enable Azure MFA for Online PowerShell Modules that don’t support MFA?

14 Replies

In this blog post I will look into how you can accomplish Azure Multi-Factor Authentication for Admins even though the Online PowerShell Module don’t support it. The key to do this is to implement and use Azure AD Privileged Identity Management, which is an Azure AD Premium P2 / EMS E5 feature.

The Problem

Administration of Online Services with PowerShell can be done with different PowerShell modules or for some scenarios setting up a remote session to the Online Service.  But not all scenarios support Azure MFA natively.

A quick overview of the main modules that DO support Azure MFA today:

All of these above supports Azure MFA as long as you are not passing in a Credential object. There are also more advanced scenarios for programmatic access with Access Token and Certificates that I will not cover here for some of these modules. The main thing is that when you create a Credential object with Get-Credential, and pass that in as a Parameter to the above modules, Azure MFA will not work if the Admin user has been configured to use that. We’ll see some examples later in the blog. Note also that if you have an older version of MSOnline or Aadrm which required the Online Sign-In assistant, these will not work with Azure MFA and you must upgrade to the latest versions.

So what about the modules and scenarios that don’t support Azure MFA. These are mainly Office 365 and Remote PowerShell:

  • Exchange Online Remote PowerShell (Update, a new Exchange Online Remote PowerShell module has now been released, but for a normal PowerShell remoting session this would still not support Azure MFA)
  • Skype for Business Online Remote PowerShell
  • Office 365 Security & Compliance Center Remote PowerShell

In these scenarios you must create a Credential object, and pass that in as a parameter when connecting to the service, thus blocking the use of Azure MFA.

A Security Best Practice for Admins

Today I just don’t find it acceptable for Admin accounts for any Online Service like Azure or Office 365, to not use Multi-Factor Authentication or some other protection mechanism, and just depend on username and password!

In addition to that, as an Organization you have to have control of your identities, employees and admins come and go, I have seen many times that Organizations still have Admin accounts for users that have left the company for a long time ago.

Most Organizations have Directory Synchronization from local Active Directory to Azure AD, making it possible to synchronize your local admin accounts. You then have a choice: Should I use synchronized admin accounts for the Admin Roles in Azure/Office 365? Or should I only create Cloud only admin accounts for this purpose?

My security best practice is to use a combination of both, so that:

  • Synchronized On-Premise Admin Accounts for the most important, permanent and sensitive admin accounts, like Global Admins, Security Admins, Azure Subscription Admins and more. These accounts will be set up to require Azure MFA, as these accounts possibly can connect to On-Premise resources.
  • Cloud Only Admins accounts for Role Based Administration, additional temporary Global Admins or other scenarios for intermittent Azure and Office 365 administration. These accounts will not be set up for Azure MFA, but I use Azure AD Privileged Identity Management to require Azure MFA when activating the role. Some of these accounts also includes service accounts for Directory Synchronization, Intune Connector etc.

The Solution

I have found that the best way to protect both type of Admin accounts is to use the Azure AD Privileged Identity Management and Azure MFA in combination so that:

  • In general all of the permanent Admin Accounts with a few exceptions are required to use Azure MFA. These Admin accounts can use all PowerShell modules that support MFA when connecting.
  • Role-based admins (for example Exchange Admins, Skype for Business Admins,..) are set up to be Temporary/Eligible Admins in Azure AD Privileged Identity Management, which require Azure MFA at activation time. After the admin role is activated, he or she can use the PowerShell modules/remote sessions that don’t support Azure MFA natively.

The downside of this solution is that Azure AD Privileged Identity Management require an Azure AD Premium P2 license or Enterprise Mobility E5 license, which will be Generally Available Sept 15th. Azure MFA are free to use for Admin accounts for Online Services.

How to set it up

In the following steps I will show how to set this up and how it will work. For the purpose for this demo I will work with my demo environment with the tenant name elven.onmicrosoft.com. I have also configured directory synchronization from my on-premise Active Directory, these users will have a UPN suffix of elven.no.

In my environment I have a fictional character called Ola Nordmann. Ola is an Exchange Admin in our Hybrid Exchange environment, and needs permissions to administer Exchange Online in Office 365 both via the management portal and via Exchange Online PowerShell.

Ola has these two accounts now in Azure AD:

image

As per the solution described, I will configure and require Azure MFA for the on-premise admin account, and for the cloud admin account I will use Privileged Identity Management and MFA for role activation.

Configure Multi-Factor Authentication

The easiest way to enable MFA for a user is via the Office 365 Admin portal at https://portal.azure.com. In the user list I find and select the admin user I want to enable MFA for:

image

The Manage multi-factor authentication will take me to the Azure AD multi-factor authentication administration page, where I find and select the admin user:

image

On the right-hand side I select to Enable for the selected user(s):

image

After that I confirm that I want to enable MFA for the user:

image

And get confirmation:

image

Now I see that the status is Enabled, this means that the user needs to log on and configure the authentication method for MFA first:

image

Configure Admin Role

Next, I will give Ola Nordmann the Exchange Administrator role, so that he can administer Exchange Online.

Back in the Office Admin portal I see that the user now has no roles:

image

I select Edit, and choose the Customized administrator and Exchange administrator role, and add the e-mail address of the user:

image

Next, I add the same Exchange administrator role to the Ola Nordmann (Cloud Admin) user:

image

So, at this time, both admin users are Exchange administrators, but only the [email protected] on-premise admin account has been configured for multi-factor authentication.

Log on and activate multi-factor authentication method for admin user

Now I will log on the [email protected] account to https://portal.office.com.

Since this admin account has been configured for MFA, I must set that up now:

image

I need to select an authentication method. In this demo I will use the Microsoft Authenticator App:

image

I select to set up and configure the mobile app:

image

I open up the Microsoft Authenticator app on my phone, and follow the instructions from above. After that I get confirmation that the mobile app has been configured.

image

Now I need to select Contact me to test the authentication:

image

At my phone I get the notification in the App and select verify, and I should be successful. Since I only have set up the mobile app, I also need to add phone number verification in case I lose access to the app. I type my mobile phone number and press next.

image

And in the last step I get an app password to use on some apps, I will not be needing this now for this demo, and click Done:

image

Back in the portal login, I will now be prompted to authenticate with my app:

image

After successfully authenticating I’m logged in to the portal:

image

And since this user has an Exchange administrator role, I can see limited information in the Office 365 admin portal and launch the link to the Exchange admin portal:

image

Try to access Exchange Online PowerShell with MFA enabled admin

First, a quick look back at the multi-factor authentication administration page, where the admin user status has now been updated to Enforced. This happens after the users have been enabled for MFA, and after they have successfully configured their authentication methods. Enforced means that they will now be required to do MFA when authenticating against online services:

image

Let’s try to access Exchange Online PowerShell with this admin user. Instructions for connecting with PowerShell for Office 365 services are detailed here: https://support.office.com/en-us/article/Managing-Office-365-and-Exchange-Online-with-Windows-PowerShell-06a743bb-ceb6-49a9-a61d-db4ffdf54fa6?ui=en-US&rs=en-US&ad=US

I launch a PowerShell window and get a Credential object:

image

After that I try to create a remote session with that credential:

image

As expected this will fail, as multi-factor auhtentication is required for the [email protected] account.

In the next part we will look at the other cloud admin user and configure the workaround using Azure AD Privileged Identity Management.

Configure Azure AD Privileged Identity Management for Exchange administrators

At this next step I log in as a Global Administrator, and if I haven’t already added the Privileged Identity Management solution, I can add it from the Azure Marketplace:

image

The first Global Administrator that set up Privileged Identity Management will added to the Security Administrator and Privileged Role Administrator Roles. After that we can manage the privileged roles. If you have previously added the solution, you will have to activate your Privileged Role administrator first.

image

When I select the Exchange Administrator role, I can see both admin accounts for my Ola admin user. These roles are assigned on a permanent basis:

image

Azure AD Privileged Identity Management will let me assign and change admin roles from permanent to eligible for temporary activation. I will do this for the [email protected] cloud admin account:

image

After I click Make eligible, the admin account are removed from permanent role and are now listed as Eligible:

image

Lets click on the Settings button for the Exchange Administrator role. At settings I can set the activation duration, email notifications, ticketing and fore some roles I can select whether to require multi-factor authentication for activation:

image

These settings can also be set as default for all roles:

image

At this point my cloud admin [email protected] has been removed as a permanent Exchange Administrator, and will require activation before he will be temporarily activated as an Exchange Administrator for one hour duration.

Log on as admin user without activation

When I log in to the Office 365 portal with the [email protected], I will see that this user is just a normal user with no admin links, This is expected as the user hasn’t activated the Exchange Administrator role.

image

Activate the Exchange Administrator Role

Next I go to the Azure portal at https://portal.azure.com still logged on as [email protected]. First I need to add the Privileged Identity Management solution:

image

After adding the solution, I can request activation for the roles I’m eligible for, in this case Exchange Administrator:

image

When requesting activation I need to verify my identity first:

image

If my account hasn’t already been set up for multi-factor authentication, it will be guided to do that now:

image

After configuring and verifying multi-factor authentication, I can now activate my Exchange Administrator role and provide a reason:

image

After successful activation I can verify the duration I will be activated for:

image

Log on to the Office 365 Portal and Exchange Admin Center after activation

After activation, I should log off and back on with my activated admin role account, and this time I will see the Exchange Admin portal:

image

Log on to Exchange Online PowerShell after activation

And finally, I can start an Exchange Online PowerShell Session with my activated account. First I get my credential:

image

Then I can create the remote Exchange Online session and import it to PowerShell:

image

And finally just try out some Exchange Online administration successfully:

image

Summary

At the end of this long blog post, we can summarize that we have accomplished the solution of adding Azure Multi-Factor Authentication for scenarios where the PowerShell Module or Remoting Session does not natively support it. This is made possible by using Azure AD Privileged Identity Management, and by making some role administrators eligible and require MFA when activating. This way they have verified their identity before they connect with the Credential object.

This is just one scenario where both Azure AD MFA and Privileged Identity Management can be used together for increased security and reduce the attack surface of having vulnerable permanent administrator accounts and roles.

I hope this blog post have been informative and helpful, please reach out or comment if you want to know more or have any questions.