Category Archives: Enterprise Mobility + Security

Speaking at Experts Live Europe 2017, Berlin!

Once again I’m very proud and excited to announce that I will be speaking at Experts Live Europe 2017, in Berlin August 23rd to 25th.

Experts Live Europe, previously known as System Center Universe Europe, is celebrating 5 years anniversary this year, after beeing arranged in Bern, Basel x 2, and last year moved to Berlin, where it was announced that the conference in the future would be part of the Experts Live Network!

SCUE16 – System Center Universe Europe becomes Experts Live Europe from itnetX AG on Vimeo.

I have been lucky to attend every single one of the previous conferences, and last year I presented a couple of sessions there as well. I have got to know some great community leaders and IT pros from all over the world at this conference, it really is one of the best community conferences around, as well as top experts and contents in sessions!

This year I will present 2 sessions:

I will also be running a Discussion Panel on “Identity, Security & Compliance” http://sched.co/B9TK , together with Simon May, Principal Program Manager – Intune, Microsoft, EMS MVP Jan Ketil Skanke, and CDM MVP Tudor Damian.

And, in addition to the already mentioned great experts, content and community, there’s also great parties there!

image

Read my recap of last years conference at the same venue here: https://gotoguy.blog/2016/08/31/experts-and-community-unite-at-last-ever-scu_europe-2016-expertslive-next/

If you haven’t already registered, and are still wondering wether to go, read more about the conference and register here: http://www.expertslive.eu.

Hope to see you there!

Get Started with Group Based Licensing in the Azure AD Portal!

Just the other day I wrote a blog post on how you could use Azure AD v2 PowerShell and Dynamic Groups based on extension attributes to set EMS license plans for your cloud and on-premises users, https://gotoguy.blog/2017/02/17/assign-ems-license-with-azure-ad-v2-powershell-and-dynamic-groups/.

And now, User and Group based licensing in the Azure AD Portal has been added in Preview! This is a long awaited feature, and works will all of your purchased services, either its EMS, Office 365, Dynamics 365, PowerBI and many more.

Let’s take a quick look on the functionality. Based on the above referenced blog post, I will use the same Dynamic Groups, where membership is defined based on values for extension attributes. So I already have configured Dynamic Groups for EMS E3, EMS E5and Office 365:

image

The new Licensing functionality are now added to the Azure AD Preview at https://portal.azure.com:

image

When I go to the Licenses blade I get a quick overview over my purchased products and total of assigned licenses:

image

When I go to All products, a list of my product subscriptions are shown, with an overview of licenses assigned, available and if any are expiring soon:

image

If I go into one of the products, I will see the already existing licensed users, which in my case are Direct assigned (I did that with the PowerShell script in the previous blog post).

image

Let’s configure Licensed Groups:

image

Click + Assign to add a group to License, I will use my Dynamic Group:

image

Then, at Assignment options, I can optionally configure individual services:

image

After clicking OK and Assign, the group has been added for processing:

image

And if I look at Licensed Users again after the change has been processed, I will see that uses now have an inherited license based on the group. Of course, the Direct assignments added by PowerShell are not removed, so I will have to remove those later.

image

In the same way I can add my Office 365 and EMS E5 Dynamic Groups:

imageimage

By the way, you can go into each group after and look at License status, and Reprocess if needed.

image

At the Group’s Audit Log we can track the license activity as well:

image

So there we have it, a long sought after functionality that I’m sure many organizations will have good use for. As this is in Preview, some more testing are should be done before setting it directly into production, and if I find anything special I will update this blog post.

I am sure there will be an announcement and blog post at the Enterprise Mobility + Security blog shortly also: https://blogs.technet.microsoft.com/enterprisemobility/

Publish the Cireson Configuration Manager Portal with Azure AD Application Proxy

Cireson will soon be releasing a new web based Portal for System Center Configuration Manager, http://go.cireson.com/cireson-portal-for-configmgr. This would make it possible to access a lot of functionality for Configuration Manager anywhere with a web browser. The Cireson Portal for Configuration Manager must be installed locally, either on the Configuration Manager server or on a server close to the Configuration Manager server and database.

This makes this an ideal candidate for Azure AD Application Proxy publishing, as we can make it available as an Azure AD App with all the features and possibilities that this can give, including:

  • Azure AD Preauthentication and Single Sign-On to the Portal
  • Assigning Users and Groups
  • Conditional Access
  • Easy access via the users Access Paneler or the Office 365 App Launcher

We will look into all this in a two-part blog post! This will also be a good opportunity to use the new management experience for the preview of Azure Active Directory management in the Azure Portal, https://portal.azure.com.

Part 1: Publish the Cireson Configuration Manager Portal with Azure AD Application Proxy
Part 2: Conditional Access and Self Service for the published Configuration Manager Portal Application (link when available)

Enable Azure AD Application Proxy

I you want to publish applications with Azure AD Application Proxy, there are some requirements:

  • You need an Azure AD tenant configured with licenses for Azure AD Premium P1 or EMS E3 Suite. Actually it is enough with Azure AD Basic licenses for AAD App Proxy, but if you want to configure Conditional Access you will need at least Premium P1. More on that later.
  • If you want to enable SSO for your internal users you have to synchronize those users via Azure AD Connect.
  • You have to Enable Azure AD Application Proxy for your AAD tenant directory, and download and install one or more Application Proxy Connectors.

The diagram below shows the communication flow from when the user launch the published application, authenticates to Azure AD, and then via the Application Proxy Connector installed internally access the web based portal. Single Sign-On is achieved via the Application Proxy Connector authentication on behalf of the user via Kerberos Constrained Delegation.

image

So the first step is to go to the Azure Portal, and open the Azure Active Directory blade, which at the moment is in preview. From there go to the Application Proxy section and make sure that the Application Proxy is enabled as shown below:

image

In the image above we also see that there already are some Azure AD App Proxy Connectors installed and active. They are also configured in two different groups, and these groups are used later when we publish the application. At the top of the blade, you can download a new Connector installation file.

Download and install Application Proxy Connector

The Application Proxy Connector must be installed on a server that can reach the internal web portal server. In this case I want to install the Connector locally on the Configuration Manager server that also hosts the Cireson Portal for Configuration Manager. I could have used one of my existing connectors, but they are installed respectively on an Azure VM environment and on a separate network from our Configuration Manager environment.

Following the download link from above, I download and start the Application Proxy Connector installation on my SCCM server.

image

During installation you must provide a global administrator admin account:

image

After finishing the installation of the connector, we will se the new connector with the server name in the portal.

We can now create a group, and place the connector installed in the group:

image

Publish the Configuration Manager Portal App

To start publishing the Configuration Manager Portal Application, go to Enterprise Applications and select Add, and from the Add your own app section select to add an “On-premises application”:

image

Next, specify the Name of the Application and the Internal Url. In this case I have installed it internally as http://configmgrportal. For External Url, you have a choice for the alias and domain. By default the alias will be the Application Name without spaces, appended with –<tenant name>.msappproxy.net.

image

You can change the domain to one of your verified domains, which I have done here together with changing the alias so that the External Url now will be https://configmgrportal.skill.no. By the way, you have to upload a SSL certificate if you want to use your own domain, either a wildcard certificate or a certificate with the appropriate FQDN. We will look at that later.

image

Note that I need to add a CNAME entry at my DNS provider as stated in the info box above. I will do that right now before I proceed.

I set Pre Authentication to Azure Active Directory, as I want everyone accessing the External Url to be a valid Azure AD user from my tenant. I also select to translate URL in headers, and select my previously configured App Proxy Connector Group.

Press Add to add the application to the directory. After that you are presented with a Quick start menu like below:

image

First I go to Properties, and optionally you can upload a logo which I have done here, note also that User assignment is required is set to yes, this means that no user cannot access the published application until I have added users or groups to it.

image

After saving I go to users and groups, and add some users to test the published application:

image

These users will now be able to launch the published application, but we have some more configuration to do first. As I want to have Single Sign-On configured for this application, I configure the following settings for Single Sign-On. I set the mode to Integrated Windows Authentication, meaning that the App Proxy Connector will impersonate any Azure AD authenticated user to the on-premises application via Kerberos constrained delegation.

I also need to specify a internal SPN for the application, which will be HTTP/<fqdn-of-server>, where the server is where the internal web application is installed. I will also specify which delegated login identity, which in most cases will work fine with user principal name for synchronized federated users.

image

After configuring Single Sign-On settings, and if you elected to use your own domain name, you need to upload or specify an existing SSL certificate. Go back to Application Proxy settings and click to view or change certificate settings:

image

After saving this configuration, the required portal configuration for the application is now complete, but optionally we can configure self service and conditional access, We will get back to that later in part 2 of this blog post.

That leaves only one more step, and that is to configure kerberos delegation for the App Proxy Connector server. In your on-premises Active Directory, find the computer object for the server you installed the App Proxy Connector on, and go to Delegation, and select to trust this computer for delegation to specified services only, and for kerberos only adding the computer name and http service for the server where the internal web application is installed. This should med the same as the internal spn you configured in the portal earlier for Windows integrated authentication.

image

Testing Single Sign-On

We can now test the application. Go to https://myapps.microsoft.com and log in with one of the assigned users. Among other published apps I will see the Configuration Manager Portal:

image

And if I launch it, I will see that I can access the Configuration Manager Portal, and I have been automatically signed in with my local AD user via Single Sign-On and Kerberos Constrained Delegation. I also see my url, https://configmgrportal.skill.no, which I can access directly if I want without going through the MyApps panel.

image

So now we have successfully published the Cireson Configuration Manager Portal with Azure AD Application Proxy, using SSO with Azure AD, and User Assignment so that only users that are pre-authenticated and assigned the application by Azure AD, will have access to it.

Stay tuned for part 2 of this blog post, where we will configure Conditional Access using Azure MFA and Device Compliance, and what Self Service functionality we have.

Assign EMS License with Azure AD v2 PowerShell and Dynamic Groups

While we are waiting for support for group based licensing in the Azure AD Portal I have created this Azure AD v2 PowerShell solution for assigning EMS (Enterprise Mobility + Security) license plans using Azure AD v2 PowerShell module and Dynamic Groups.

The PowerShell CmdLets used here requires the Azure AD v2 PowerShell Module, which you can read about how to install or update here: https://gist.github.com/skillriver/35fba9647fbfbe3e99718f0ad734b241

Source of Authority, Attributes, Sync and Dynamic Groups

In my scenario I want to use extension attributes to automatically calculate membership using Dynamic Groups in Azure AD. The members of these groups will be assigned the EMS licenses.

Most organizations will have an on-premises Active Directory synchronizing to Azure AD, so the source of authority is important for where I set the value of the extension attributes, as I want my Dynamic Groups to calculate membership for both On-premise and Cloud based users (I have some Cloud based admin account I want to license as well).

So, lets take a look at my local Active Directory environment. If you have Exchange installed in your organization, you will have extended the schema with extensionAttribute1..15.

But in my case, I never have installed any versions of Exchange in my current environment, and only used Exhange Online, so I don’t have those attributes. Instead I have msDS-cloudExtensionAttribute1..20.

So I decided on using the following attributes locally in AD:

image

I have previously used ENTERPRISEPACK (SkuPartNumber for Office 365 E3) for licensing Office 365 E3 plans. In this scenario I will use the msDS-cloudExtensionAttribute2 for either EMS (SkuPartNumber for EMS E3) or EMSPREMIUM (SkuPartNumber for EMS E5).

You can also use Active Directory PowerShell to set these values on-premises:

image

Note that if I had Exchange installed, I could just have used extensionAttribute1 and extensionAttribute2, and these would be automatically synchronized to Azure AD in an Exchange Hybrid deployment. However, in my case I need to manually specify the option for Directory extension attribute sync in Azure AD Connect:

image

And then selecting to synchronize those two selected attributes:

image

After these Directory extensions are configured and synchronized to Azure AD, I can check these attributes with the following AAD v2 command:

Get-AzureADUser –ObjectId <youruser> | Select -ExpandProperty ExtensionProperty

In my environment I will find these attributes:

image

Note that the msDS_cloudExtensionAttribute1..2 has now been created in Azure AD for me, and been prefixed with extension_<GUID>_, where the GUID represent the Tenant Schema Extension App:

image

So now I know that my on-premises users with values for msDS_cloudExtensionAttribute1..2 will be synchronized to the extension attributes in Azure AD. But what about users that are source from Cloud? There are no graphical way to set these extension attributes, so we will have to do that with Azure AD v2 PowerShell. In my example I have a Cloud admin account I want to set this attribute extension for (scripts are linked later in the blog):

image

With that, I now have configured the users I want with the extension attribute values, and are ready to create the Dynamic Groups.

Creating Dynamic Groups for Assigning EMS Licenses

Earlier in the blog post I mentioned that I wanted to use the msDS_cloudExtensionAttribute2 for assigning either EMS E3 or EMS E5 licenses. If I run the following command, I get my Subscriptions, here listed by SkuId an SkuPartNumber. EMSPREMIUM refers to EMS E5, while EMS refers to the original EMS which is now E3.

image

On that basis I will create 2 Dynamic Groups, one that looks for EMSPREMIUM and one that looks for EMS in the extension attribute. You can create Dynamic Groups in the new Azure AD Portal, or by running these PowerShell commands:

image

After a while memberships in these dynamic groups will be processed, and I can check members with the following commands:

image

In my environment I will have this returned, showing users with membership in the EMS E3 and EMS E5 group respectively:

image

Before I proceed I will save these memberships to objects variables:

image

Assigning the EMS licenses based on group membership

With users, attributes and dynamic groups membership prepared, I can run the actual PowerShell commands for assigning the licenses. I also want to make sure that any users previously assigned to another EMS license will be changed to reflect the new, so that they are not double licensed. Meaning, if a user already has an EMS E3 license, and the script adds EMS E5, I will remove the EMS E3 and vice versa.

The full script is linked below, but I will go through the main parts here first. First I will save the SkuId for the EMS subscriptions:

image

Then I will loop through the membership objects saved earlier:

image

Next, create License Object for adding and removing license:

image

Then create a AssignedLicenses object, adding the AssignedLicense object from above. In addition, I check if the user has an existing EMS license to be removed, and if so add that SkuId to RemoveLicenses. If there are no license to remove, I still need to specify an empty array for RemoveLicenses.

image

And then, update the user at the end of the loop:

image

After looping through the EMS E3 members, a similar loop through EMS E5 members:

image

So to summarize, with this script commands you can assign either EMS E3 or E5 licenses based on user membership in Dynamic Groups controlled by extension attributes. In a later blog post I will show how we can consistenly apply these licenses, stay tuned!

Link to the full script is below:

Link to script for managing and listing extension attribute properties for your users:

Session Recap, PowerShell Scripts and Resources from session on Azure AD Management Skills at NICConf 2017

Last week at NICConf I presented two sessions on Management of Microsoft Azure AD, Application Publishing with Azure AD – the New Management Experience! and Take your Azure AD Management Skills to the Next Level with Azure AD Graph API and Powershell!

In the last session i presented demos and scripts with some technical details, so in this blog post I will link to those PowerShell scripts together with some explanations. See also my slides for the sessions published here: https://docs.com/jan-vidar-elven-1/7677/nicconf-2017, and the session recording might be available later which I will link to.

First i talked about the new Azure AD PowerShell v2 module and install info:

Then connecting and exploring some objects and license info:

Then performing some Administration tasks including creating Dynamic Groups, setting user thumbnail photo, adding licenses and changing passwords:

In the next part of my session I went on to talk about the Azure AD Graph API and the Microsoft Graph API. The Microsoft Graph API will eventually be the “one API to rule them all”, as Azure AD also can be accessed by that API, but there are still use cases for the Azure AD Graph API.

In either case, to be able to use the APIs you must create and register an Azure AD Application of type Web App/Api, and give that Application the needed permissions to access the APIs. I showed in my session how to do this in the portal, and here you have a PowerShell Script for creating that same type of Application, this example for accessing the Azure AD Graph API:

Note that for the above script, you will need to note some output and manual operations:

  • Take a note of the Application ID, you will need that later:
    azureadapp
  • Take note of the Key Secret, you will need that later also:
    azureadappkeysecret
  • Application must be manually granted permission here, as this per now cannot be automated with PowerShell:
    azureadappgrantpermission

By the way, you should newer share this App Id and key secret publically (as I have just done here 😉 Other people could use that same information to access your APIs and Azure AD info, so take care to protect that info! (Of course I have deleted that info after showing this here 😉

Now, with this App registered in Azure AD, we can now start managing Azure AD via REST API calls, for example from PowerShell. The following script shows how we can get Self Service Password Registration Activity via the Azure AD Graph API, specifically we will use the Reporting API (https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-reports-and-events-preview). Note that the script will need the App Id and Key value noted from above:

With that last export to a Csv file I can import it to Power BI as a table, and create a report and a dashboard on it, for example showing which password reset registration method the users configured, what user and role type did the registration and the count and date for the registrations:

PowerBIReport.PNG

In the session we also looked at the new Content Pack for Azure AD, showing sign-in and audit events, and also how you can get data from the Microsoft Graph API using a OData Feed:

I hope this scripts will be as useful for you as it is for me! Good luck with taking your management of Azure AD to the next level with Azure AD PowerShell and Graph APIs!

How to use PowerShell script for setting Azure AD Password Reset Writeback On-premises Permissions

When you configure the Azure AD Premium Self Service Password Reset solution on your Azure AD tenant and then the Azure AD Connect Password Writeback feature, you will need to add permissions in your local Active Directory that permits the Azure AD Connect account to actually change and reset passwords for your users  , as detailed here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords-getting-started#step-4-set-up-the-appropriate-active-directory-permissions.

I wrote this PowerShell script that helps you configure this correctly in your domain/forest. Some notes:

  • You can use it in a single-domain, single-forest domain, or in a multi-domain forest, just remember to specify a Domain Controller for the wanted domain, and for the domain the Azure AD Connect account is in.
  • You have to find the Azure AD Connect Synchronization account, it would be MSOL_xxxx.. if you have used Express settings, or a dedicated account. Look at current configuration for details.
  • You can specify an OU for your users, and if inheritance is enabled all subordinate users and OUs will inherit the permissions. If not, please run the script once for each OU you want the permissions to be applied for.

Here is the script:

Hope the script will be helpful!

Protecting Norwegian National ID Number with Azure Information Protection and RMS

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.