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!

Schedule Tesla Heating with Microsoft Flow from Calendar @microsoftflow

My Skill colleague Pål-Andre Kjøniksen wrote a blog post on how he can control the heating in his Tesla Model S based on his Office 365 Calendar appointments and Microsoft Flow.

https://www.skill.no/blogg/samhandlingsbloggen/2017-01-25-microsoft-flow-styrer-varmen-i-teslaen/.

The blog post is in Norwegian, but it should be fairly simple to follow the steps, where the idea was that if he creates a Calendar appointment that starts with “Tesla:”, the heating will start up 20 minutes before that, making sure that the car is warm when he drives off.

Exchange Online PowerShell with Modern Authentication and Azure MFA available!

A while back I wrote a blog post on how you could use Azure AD Privileged Identity Management to indirectly require MFA for Office 365 Administrator Roles activation before they connected to Exchange online via Remote PowerShell. See https://gotoguy.blog/2016/09/09/how-to-enable-azure-mfa-for-online-powershell-modules-that-dont-support-mfa/.

In december a new Exchange Online Remote PowerShell Module was released (in preview), https://technet.microsoft.com/en-us/library/mt775114(v=exchg.160), that uses Modern Authentication and that supports Azure Multi-Factor Authentication. Lets try it out:

First you need to verify that Modern Authentication is enabled in your Exchange Online organization, as this is not enabled by default: https://support.office.com/en-us/article/Enable-Exchange-Online-for-modern-authentication-58018196-f918-49cd-8238-56f57f38d662?ui=en-US&rs=en-US&ad=US

In my Exchange Online organization I verify that Modern Authentication is enabled:

image

Next logon to your Exchange Online Admin Center, and go to Hybrid to download and configure the Exchange Online PowerShell Module:

image

The configure button activates a click once install:

image

After installation I’m ready to connect:

image

Lets try it out on a MFA enabled admin user:

image

And as expected, I’m prompted to provide my verification code:

image

And after verification I can administer Exchange Online:

image

So with that we are finally able to log in to Exchange Online PowerShell more securely with Azure Multi-Factor Authentication as long as Modern Authentication is enabled for your organization!

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.

Renaming and rebranding my blog

I have been thinking about this a while, as my previous blog URL address systemcenterpoint.wordpress.com and title SystemCenterPoint not longer accurately reflected the blog content I produce.

When I created the blog for over 4 years ago, I was heavily invested in System Center products, and especially Service Manager and Operations Manager, and most of my content published on the blog was related to that.

These days, I still work a lot with SCSM and SCOM, and with partners such as Cireson, SquaredUp and itnetX, but also more and more with Cloud and Azure based solutions such as Operations Management Suite. The same with System Center Orchestrator, where I now automate more with PowerShell and Azure Automation than Orchestrater Runbooks.

In addition, being awared Microsoft MVP for Enterprise Mobility I also focus a lot on Identity and Access Managment and Security with Azure AD and EM+S!

So, what to rebrand my blog URL and Title to?

When I was at the MVP Summit recently I was very inspired by James Whittaker that had a session on the importance of story telling. And he challenged us, what is your story?

My story is not finished, it is a working progress. But if I should start somewhere I would be saying to anyone that asks that: “I’m the Go To Guy!”

I realize that this title is not exclusive to me, many people are Go To Guys in their workplace or community. But I’m already labelled (one of the) Go To Guy in my workplace, amongst many customers and as a MVP I’m aspiring to be a Go To Guy for many in the communities I participate in.

So, thats why my blog now has a new URL: http://gotoguy.blog ! And the blog title has been updated to GoToGuy Blog.

Looking forward to produce more great content on the blog!

(PS! All old references to systemcenterpoint.wordpress.com will of course work for the future until eventually not needed anymore)