Encrypting disks on an Azure VM

Due to all the new privacy and data-protection rules like GDPR, I see a lot of companies looking at using disk encryption on their servers. In this case, a customer asked me to enable Azure Disk Encryption on their Azure VM’s.  Azure Disk Encryption encrypts the disks for your Azure VM at rest using the known Bitlocker technology. This is free -as in free beer. There is no extra charge for encrypting you disks in Azure. The crypthographic keys  are stored in Azure Key Vault. These cryptographic keys are used to encrypt and decrypt virtual disks attached to your VM. You retain control of these cryptographic keys and can audit their use through the Key Vault. An Azure Active Directory service principal is used for issuing these cryptographic keys as VMs are powered on and off.

Proces for encrypting a VM

The process for encrypting a VM is pretty straight forward:

  1. Create a cryptographic key in Azure Key Vault
  2. Configure the key to be usable for Azure Disk Encryption
  3. Create an Azure Active Directory service principal to be able to read the key
  4. Run the PowerShell command to encrypt your virtual disks, specifying the Azure Active Directory service principal and appropriate cryptographic key to be used
  5. The Azure AD service principal will request the required cryptographic key from Azure Key Vault
  6. The virtual disks are encrypting using the provided key

There are some requirements and limitations to keep in mind. Encryption can only be applied to VM’s in de standard tier and all resources (Key Vault, Storage Account and VM) should be in the same region. You can’t use Azure Disk Encryption for VM’s created in the classic deployment model and you can’t update the key on already encrypted VM’s.


So, let’s code!

In the following examples, we’ll use PowerShell to enable Azure Disk Encryption on the ‘myVm’ Virtual Machine in the ‘myResourceGroup’ resource group. All resources are based in the West Europe region. Of course, before you start, make sure that you are running the latest AzureRM module in Powershell.

First of all, we’ll set some variables and register the Azure Key Vault provider.

Next, we’ll create the key vault. I choose to use a specific key vault for storing my key, but you can use an existing key vault. Of course you can freely choose the name of your vault 🙂 Make sure to enable the key vault for disk encryption.

Next, we’ll create a software-protected key in the vault to use with Azure Disk Encryption. This is the key that will actually be used for encrypting and decrypting your disks. Again, pick your own name for the key.

When virtual disks are encrypted or decrypted, you specify an account to handle the authentication and exchanging of cryptographic keys from the key vault. This account, an Azure Active Directory service principal, allows the Azure platform to request the appropriate keys on behalf of the VM. We’ll create the service principal using the following code. When choosing your password, keep the Azure AD password policies and restrictions in mind.

After creating the service principal, we have to set permissions on the key stored in the key vault to be read by the service principal.

So, now all prerequisites are met to start encrypting disks. We kick off the encryption process on our VM

You will be prompted to continue with the encryption. Once you accepted, the encryption process will be started and the VM will be restarted in the process.

Once the process has completed, you can check the status with the following command:

The output will look something like this:

That’s it! You just encrypted your disks using Azure Disk Encryption. Want to know more about this feature? Check the documentation.


Microsoft Authenticator to support account backup & recovery

Good news for everyone who, like me, uses the Microsoft Authenticator app for all his (or hers) multifactor authentication needs: a much requested feature will soon be available!

Microsoft announced that they will soon start rolling out the account backup and recovery functionality for their authenticator app. This way, when you switch devices, you won’t need reconfigure all your account credentials on the new device.

The Microsoft Authenticator app beta for iOS already supports this feature, so I went ahead and configured the backup functionality.


The backup is encrypted with your personal Microsoft-account and then stored to iCloud. Because building the foundations using iCloud storage simplified the development process, Microsoft is starting the roll-out on iOS devices the next few weeks. After that, the function will become available in the Android-app too.

More information, and a form to sign up for the beta-release of the Authenticator app for iOS, can be found here.

Teams guest access: user experience

Recently, a long awaited feature in MS Teams was released: access for guests from outside your tenant. But how does this work? I took it for a test drive 🙂

I started off by logging in to MS Teams on my 365dude.nl tenant.

From here, I tried adding my business account as a guest to the team. Unfortunately, that account was not recognized, so I can’t add it to the team.

I decided to go to the Azure AD control panel, to add the account from there.



After doing so, I receive an email on my business account to welcome me as a guest to the tenant.

After completing the invite, I am able to invite my business account to my tenant as a guest from within the Teams application. For example. I can @-mention the account just like I would with internal users.

When I start the Teams app and login using my business  account, I see both tenants and can switch between the two.

After switching, I can use the tenant just like I would as a normal user, for example be viewing contact information or replying to messages.

As a final test, a few days later I decided to add someone who was not previously known as a guest in my tenant. This time, probably due to an update of the Teams application, I could just type the e-mail address and add the guest that way. No need to revert back to the Azure AD portal!

So there you go. Adding guests to your MS Team to improve collaboration is easy as that! If you feel the need to make de display names of your guests a little more appealing, you can do so by simply editing the guest user object in the Azure AD Portal.

Whoomp, there it is: guest access for MS Teams!

It’s been a long awaited feature for the app that should be Microsoft’s answer to Slack: collaborating with users from outside your organization in Teams. While the feature has been announced earlier, it has been postponed moments before it’s initial launch date. But it’s finaly here: in this blogpost the general manager for Teams announces guest access for Teams.

Of course, for an app that aims at facilitating collaboration and fighting shadow IT, when rolling out externa access security should be a big priority. Microsoft accomplished this by leveraging Azure AD B2B Colloboration. This enables, for example, conditional access policies to be applied to guest accounts.

Along with this major feature, new developer tools for MS Teams have been announced on the MS Dev Blog.

Azure AD Group Based Licensing

When working with larger Office 365 and / or EM+S deployments, one of the pains for me has always been the automation of license assignment. You can provision users in Azure AD (and thus in Office 365) automatically using Azure AD Connect, and you could even add some magic with some PowerShell scripts to assign a license to these users based on OU or group-membership in your on-prem AD. The removal of these licenses takes even more scripting, where you would need to compare you on-prem group membership with the active licenses and remove licenses when needed.

About two weeks ago, Microsoft announced something to fill this gap: Azure AD Group based licensing. Currently, this feature is available in public preview. While in preview, you’ll need a paid Azure AD subscription to use the feature, like the one included in EM+S. Just a plain Office 365 tenant won’t be sufficient. When the feature hits GA, this prerequisite will be lifted.

Using the feature is as simpel as it sounds. From the (new) Azure Portal, you navigate to the Azure AD resource and click the ‘licensing’ tab. From there, you can navigate to all the licenses that are available in your environment.

By clicking through to one of the available licenses, you get the option to assign this license to a group.

All Microsoft Online services that require user-based licensing are supported and are displayed in this pane.

When selecting the ‘groups’ option, you can select the group to assign this license to. and search for the group you would like to use. This group can live solely in Azure AD, or can be a security group synced from you on-prem AD.


You can specify which parts of the license you would like to assign, you can create a pretty fine-grained solution using various groups to enable or disable specific features.

All in all, this is a pretty neat solution to provide some ease in managing user licenses for Microsoft Online services.

There is some good documentation on this feature on the Microsoft website. Of course, as is a feature that’s currently in public preview, there are some known issues and limitation, which are also pretty well documented.

For me, I can’t wait to get this feature implemented at some of the larger tenants I manage, to ease the administrative tasks of on- and offboarding users.

Connect to O365 Powershell with one command

For a few years, I’ve been using a simple script to connect to Office 365 using Powershell. In stead of typing all the commands needed to connect to both Azure AD and Exchange Online, I use a small piece of code placed in my Powershell profile to do all this for me. I simply type open-msolconnection from my Powershell prompt, specify my username and password and that’s it.

I’ve received some questions about this little function, so I decided to share it on GitHub. You can find it here. Enjoy!

Pass-through authentication and SSO

In an earlier blogpost I wrote about the new ‘pass-through authentication’ feature that is in public preview in the new Azure AD Sync client.

One of the most common reasons to use ADFS in an Office 365 setup, is that it allows you to do Single Sign-On. You only have to authenticate once, when you log on to your domain joined device, and your Kerberos ticket is used to authenticate you against Azure AD and therefore Office 365.

With the pass-through authentication feature, you get the same benefits. Because the PTA agent authenticates you against your on-premises Active Directory, you can use PTA to do single sign-on as well. So lets take this setup for a test-drive!

Basis of this test is the setup from my previous blog: an on-premises AD with PTA enabled in Azure AD Connect combined with the 365Dude Office 365-tenant. I added a Windows 10 machine to the mix, and domain-joined it to the on-premises AD. I use the Mr. Dude account to log on to this machine.

There are a few prerequisites to take into account when doing SSO. Mainly, they regard the OS and browser used. It is required to use a Windows machine, as it uses Kerberos for the underlying authentication. When using Windows 10, 8.1 or 8 clients, Internet Explorer, Chrome and Firefox are supported, where Edge isn’t.  Lower Windows-versions aren’t supported. When installing Azure AD Connect with the PTA / SSO option, a computer account is created in AD to handle your authentication requests.

First, we need to make sure that the Office 365 tenant is configured to allow OAuth. We do this with one single line of PowerShell:

Furthermore, we need to add the Microsoft authentication servers to the Intranet zone of the browser’s security settings. They need to be explicitly added to the machine’s Intranet zone, so that the browser will automatically send the currently logged in user’s credentials in the form of a Kerberos ticket to Azure AD. The easiest way to add the required URLs to the Intranet zone is to simply create a group policy in Active Directory.

There are two URL’s that need to be configured here:



When done, the GPO should look as follows:

That’s it! After configuring our tenant and setting up the URL’s to be in the Intranet zone, you can ‘single sign-on’ to your Office 365 service.

So, what’s the user experience here? Let’s check it out.

After logging on the machine, we open IE and navigate to the https://outlook.office.com URL.

We are prompted to enter username and password. After we enter the username part, and navigate to the password field, the computer checks for a Kerberos ticket for this username. When it exists, the client is automatically logged on without the need of entering the password.

Well, it’s a bit hard to capture that on a screenshot. But you catch my drift, right? 😉 When the login completes, we just find our Outlook for the Web logged on and ready to use.

So that’s the webmail part. Most of my clients however, prefer to use Outlook as part of the Office suite for their e-mail work. How does SSO work there? Well, almost in the same way.

Prerequisite for SSO to work with client apps, is that the apps support modern authentication. So for our Windows-based clients, that will be Office 2013 and 2016. For this test, I used Office 2016.

When first starting Outlook, we are prompted to connect to Office 365.

So lets do just that. When we click the ‘connect’ button, we get a login screen equal to the one being used in the Outlook for the Web based interface.

And there we are. After checking the username and navigating to the ‘password’ field, the dialog box checks to see if a Kerberos tickets exists for this account and when it does, it uses that to log on to the Office 365 service. No further user interaction is required, It Just Works.

So, it’s a wrap. This single sign-on functionality provides you with all the ease of use you have with ADFS, without the need of a complete ADFS infrastructure. Ofcourse, when you plan on (or need to be) running ADFS in your environment for single sign-on with other applications, such as CRM or ERP software for example, there is no use in using PTA with SSO for Office 365, you just take the ADFS route. If you however want to provide your user with the same experience without the need for the infrastructure, PTA with SSO can be a great alternative!


AAD Pass-through authentication checked out

Exactly one week ago, Alex Simons announced what he called ‘the biggest news of the year’: the public preview of Azure AD Pass-through authentication and seamless single sign-on.

I tweeted something about how this would be the start of the end of ADFS for Office 365, but is it? Time to take this new options for a test drive!

First, some side-notes. The new functions are in public preview, which means it’s ‘beta’ and SLA is non-existent. You should therefore not use it in production environments. But I guess you’re smart enough to know that.

So, for the test I created a simpel AD domain 365dude.local, with one user: Mr. Dude. This will be the user I will be syncing to my existing Office 365 tenant that houses 365dude.nl. To make synchronisation easier, I added 365dude.nl to the list of UPN-suffixes in my AD domain and changed the UPN of this user to mrdude@365dude.nl.

I enabled the dirsync functionality on my Office 365 tenant using PowerShell:

After that, I start with installing the Azure AD Connect tool

I guess you’re smart enough to know how to install AADConnect, so I’ll just focus on the new and shiny stuff here.

In the ‘user sign in’ screen, we can select how we want to handle sing in requests for our synced users. Of course we can use password sync or ADFS, but we’ll choose the new ‘pass-through authentication’ option.

So, what does this new pass-through authentication mechanism do? It relies on a connector which runs in local network. When you authenticate through the Office 365 portal (or a supported client app), your authentication request is sent to the connector over a secure channel. The connector will then check your credentials against your on-prem AD. So, no more syncing of password hashes to the cloud and using AAD as your authentication source: you authenticate directly to your on-prem AD. Just like you would when using ADFS, but without the need for the complete ADFS infrastructure.

On the ‘optional features’ tab, you can still choose to do password sync. This way the on-prem passwords are still synced to AAD, so you can easily fall back to authenticating to AAD if you want to, because the passwords are already in place.


In this screenshot, I also selected the ‘password write-back’ option. To use this, you need an AD Premium license.

You get some information on what the software will do, and the installation will continue.

Once completed, I can find the user from my on-prem AD in the active users overview of Office 365 and assign a license.

Remember, with pass-through authentication when you sign in to Office 365, your authentication is routed through the connector in your local network and your credentials are verified against your on-prem AD. Thus, you can find eventlog messages for your sign-in request with Office 365.

So, will this be the end of ADFS? In some ways it will, I guess. You can get the same functionality, without the need of the complete ADFS infra. And ofcourse, with the pass-through authentication mechanism in place, you don’t need to sync your (hashed) passwords to the cloud to get the same sign-in experience, which could please your security officers. On the other hand, many (larger) organizations already have the ADFS infrastructure in place to get single sign-in functionality with other LOB applications. If you already went down that road, you can simply use that to connect Office 365, too. Another disadvantage is that when you use directory synchronisation to connect your on-prem AD to AAD, you’ll need an on-prem Exchange Server to perform certain management tasks, such as adding aliases to a mail enabled user. For smaller organizations, this can be reason to not choose the directory sync option all, be it with or withou pass-trough authentication. I expect this will be something that Microsoft will fix somewhere in the next year, but that’s just a guess.

Want more information on this new (preview) functionality in AAD Connect and Office 365? Be sure to check out the official documentation.

Change the Office 365 language for synced users

Office 365 is all about letting users set up their own environment and preferences. One of those preferences can be the language in the Office 365 interface. I work for a company in The Netherlands, where everyone speaks Dutch, but I still prefer my computer and software to be in English. In Office 365, I can set this up… Unless I’m a ‘synced user’, a user who originates in an on-prem AD and that is being synced to the cloud.

Even when I ask my administrator, he can’t set the preferred language via the appropriate PowerShell cmdlet

This will result in an error:

So, what causes this error? It’s pretty simple. When you use DirSync (or the newer AADSync), the on-prem directory is leading. You could say the sync is one-way: changes sync from on-prem to the cloud, but not the other way around. Therefore, you can’t make changes to properties of the identity in Office 365. So, if you want to change the preferred language for such users, you should do this in the on-prem AD.

All available language codes are listed here. And keep in mind, if your preferred language is not set, it will default to English.