Need to Know podcast–Episode 275

Join for an episode with MVP Rory Braybrook where we learn more about modern identities, especially Azure including B2B and B2C. Identity is so critical to everything we do in IT these days it is important to have a refresher to understand what’s what and how it can be used effectively. I’ll also bring you the latest news and updates from the Microsoft cloud world so listen in and share your feedback.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020.

Brought to you by

Take a listen and let us know what you think –

You can listen directly to this episode at:

Subscribe via iTunes at:

The podcast is also available on Stitcher at:

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.


Rory Braybrook – LinkedIn, Authory

Windows 11: A new era for the PC begins today

Welcome to the new Whiteboard

Mailbox storage limits

Microsoft Ignite

How cyberattacks are changing according to new Microsoft Digital Defense Report

Microsoft Digital Defense Report

Defending Windows Server 2012 R2 and 2016

End to End email protection with Microsoft 365–Part 4

This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:

End to End email protection with Microsoft 365 – Part 1

End to End email protection with Microsoft 365 – Part 2

End to End email protection with Microsoft 365 – Part 3

These articles are based on a model I have previously created, which you can read about here:

CIAOPS Cyber protection model

designed to help better explain expansive security included with Microsoft 365.

In previous parts, we covered how an external email was delivered into the Microsoft 365 service and all the protections that it passed through until it finally came to rest in the Data container (user’s inbox) ready to be viewed. The next step in the process will therefore for the user to fire up their device to read the email. This article will therefore focus on the protections available for that device.

For the sake of simplicity we’ll focus on that being a modern device running at least a Windows 10 Professional. Of course, email from Microsoft 365 can be viewed on just about any devices these days, Windows or not, and all of these have unique and overlapping protections. However for the sake of brevity let’s just focus on the more common Windows 10 device for now.

A range of hardware device protection is available and recommended including:

and should already be in place to protect the device.

We will also assume that the Windows device is fully up to date

How to keep your Windows computer up to date

The device in question should also already live inside the Device container as shown in the above model. This is largely achieved thanks to being joined to Azure Active Directory (AD):

Azure AD joined devices

Join your work device to your organization’s network

Tutorial: Join a new Windows 10 device with Azure AD during a first run

When that device is turned on we want it to complete the:

Secure Windows boot process

Once the machine has booted and before the user has logged into the machine, thanks to being Azure AD joined, Microsoft Endpoint device policies have already been pushed and implemented on that machine per:

Manage device security with endpoint security policies in Microsoft Intune

Such policies could be enforcing disk encryption, implementing Attack Surface Reduction (ASR) and so on.

Importantly, you can also enforce device compliance policies to ensure devices meet a security standard before they are allowed to access any data:

Use compliance policies to set rules for devices you manage

All of this is achieved via:

Microsoft Endpoint Manager

which I have also written a whole series of articles to help provide a better understanding of the role that it plays with device security. You can read these articles here:

Modern Device Management with Microsoft 365 Business Premium–Part 1 of 10

Assuming that the device has booted and successfully completed all the protection processes associated with that have been correctly applied, it is now time for the user to login to that devices. This means that we now follow the User connector in our model shown above, into the Service container from outside, then onto the Device Container and so on.

The user’s identity is protected inside the Microsoft 365 service via a variety of mechanisms. When logging into a Windows 10 device they will typically need to provide their account and password details that were set up with the service. However, best practice would now be to use Windows Hello for Business.

Windows Hello for Business Overview

Windows Hello addresses the following problems with passwords:

  • Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.

  • Server breaches can expose symmetric network credentials (passwords).

  • Passwords are subject to replay attacks.

  • Users can inadvertently expose their passwords due to phishing attacks.

Many mistakenly believe that the Windows Hello PIN is all that protects a users access to device and the service when at login. That is in fact not the case as Windows Hello leverages the TPM hardware to provide a highly secure login to the service.

Why a PIN is better than a password

How Windows Hello for Business works

These days just a login and password are not enough to secure any identity, you MUST implement Multi Factor Authentication (MFA). Why? As Microsoft will tell you:

Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

Your Pa$$word doesn’t matter

All your creds are belong to us!

So MFA, along with a number of other recommended steps, are what can be done with Microsoft 365 to protect user identity.

Five steps to securing your identity infrastructure

Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. Importantly, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. Many don’t appreciate that correctly configured Windows Hello for Business DOES provides MFA when users access their devices, while making the device login process seamless. If you are however still concerned about this ‘single credential’ being compromised then you can also implement:

Multifactor Unlock

It is also important to remember that MFA is provided FREE on all Microsoft 365 accounts and support a variety of methods including authenticator apps, hardware token and more.

Enable multi-factor authentication for free

Once the user has correctly provides a login and password, then completed their MFA challenged (or equivalent thanks to Windows Hello for Business) they would then be subject to Azure AD Conditional Access.

It is important to remember that Azure AD Conditional Access is evaluated AFTER a successful login from a user, not before! This means that it can’t be used to block things like Password Spray Attacks.

Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action.

Conceptual Conditional signal plus decision to get enforcement

What is Conditional Access?

For example, user account access can be blocked if it comes from outside a specific country or region.

Conditional Access: Block access by location

and enforcing MFA

Conditional Access: Require MFA for all users

Conditional Access: Require MFA for administrators

Once any Conditional Access policies have been met the user will be able to login to their device. At this point additional Microsoft Endpoint Manager policies will be applied to that specific account now logged in. Such policies could restrict applications the user has access to, limit Windows functionality and so on.

Remember, all of these protections have taken only during the user has logging onto their device. They have not as yet run an application like Outlook to read the inbound emails. That is what is going to happen next and I’ll cover that process in the next part of the series, so stay tuned.

End to End email protection with Microsoft 365–Part 5

Azure AD Sign-in error code look up


When you are looking at various entries in the Azure AD logs you will find, under the Basic Info tab, a Sign-in error code and directly below that a Failure reason field as shown above.


The above, shows you these fields in more detail.

You may not be aware but if you navigate to the web site:


and plug in the Sign-in error code from the event, you should see information like that shown above. Most of it should match what the Failure reason field says. There can however, also be additional information in there that may help you when it comes to troubleshooting these events.

Determining legacy authentication usage

I’ve spoken previously about the need to eliminate basic authentication from your environment:

Disable basic auth to improve Office 365 security

The unfortunate reality is that some legacy applications could be using and can ONLY use legacy auth! So, you don’t want to necessarily disable it across your tenant without first understand who or what maybe using legacy auth.


One way you can see this is by navigating to your Azure Active Directory in the Azure portal for your tenant. You then need to select the Sign-ins options on the left under the Monitoring heading towards the bottom as shown above. You should then see a list of events display on the right. At the top of this pane select the Columns menu item.


From the pane that appears from the right ensure you have the option Client app selected, as shown above.


Next, select the Add filters button at the top of the list of events as shown above. From the list that appears select Client app and then the Apply button at the bottom.


A Client app option should now appear at the top of the list as shown. It will typically show None Selected.


Select the new Client app button and a list of items will be displayed as shown above. From this list, select all the items under the Legacy Authentication Clients heading.


When you now click away, the list of events should be filtered to only those events that match the use of Legacy Authentication. You can select any of these to get more information about the event including who or what generated this.

Armed with this knowledge you can now start working whether upgrades or additional configuration is required in your environment to minimise the attack surface area of Legacy Authentication in your environment.

Using the Microsoft Graph with multiple tenants

In a recent article:

Making PowerShell automation easier with the Microsoft Graph

I showed how to use the Microsoft Graph to embed an Azure AD application in a single tenant and then use that to make Graph queries against. What happens when you want to that across multiple tenants?

To achieve this you’ll need to basically do three things:

1. Embed a ‘static’ Azure AD application in all the tenants you wish to access.

2. Give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access the tenant values.

3. Run a Graph request against these Azure AD applications in each tenant and extract the results you want.

This article is going to look at Step 1 of this process.

So, the task at hand is to create a ‘static’ Azure AD application in all the tenants we want to access. I have detailed how to achieve this manually before here:

Using interactive PowerShell to access the Microsoft Graph

That may prove time consuming if you wish to do this across many tenants, so I have automated it via a freely available program here:


You can download the file into any directory on your machine. Best best is to use a Windows 10 machine that already has the AzureAD PowerShell module installed. This program will also generate a number of configuration files in the current directory for each domain you connect to.


Running the program will launch the PowerShell script as shown. You’ll then be prompted for the name of your Azure AD application. This is the display name that will appear inside your Azure AD. This name will be the same across all tenants you connect to. Here I’ve chosen to call my Azure AD application ciaops.


You’ll then be prompted for the email address of a tenant administrator with the rights to create an Azure AD application.


You’ll then be take through the normal sign in process for that tenant with that user as shown above. This will include any MFA if required.


The tenant will be check to see if an existing Azure AD application of the same name already exists and if it does you’ll see a warning like shown above. The program will then skip adding an Azure AD Application to this tenant and move on to the next tenant.


Assuming no Azure AD application of the same name exists in that tenant you’ll see that a new Azure AD application of that name is created. When a token is created in a tenant there are fours pieces of information that will need to be saved:

1. Application ID

2. Object ID

3. Application secret

4. Tenant ID

Each of these will be written to a secure configuration XML file I’ll explain in detail below. For now, just appreciate that these values need to be written securely to files so they can be used later. To achieve that, the program uses the get-credential PowerShell command to capture these securely to be written.


To complete this process all you need to do is use the Paste command (i.e. CTRL+V) when prompted at the password field as shown.


So here, simply hit CTRL+V and then ENTER. The actual value you are pasting is a few lines up in the display as you can see above if you need it.


You’ll need to complete that process four times for each variable as shown above.

You are then prompted for the next domain you wish to add an Azure AD application to. You repeat the same entry process for each new domain you wish to use.


When you have no more domains to configure, simply press Enter at the admin domain prompt. At that point, the program will disconnect from any Azure AD and use the captured credentials to check whether it can access all these tenants. To do this, it reads from the saved configuration files and makes a basic read request to the Microsoft Graph using the Azure AD application details for each tenant to verify success. It merely tests that it can get the Graph API for that tenant.

At this point you now have an Azure AD application of the same name, inside each tenant you configured, with no permissions to anything with the Graph.


If you now return to the directory where you ran the program from you’ll see a number of additional files as shown above.

The graph-adapp-set.txt is a log of the whole process so you can see what has happened.

You’ll also see four XML files per tenant. These contain the important variables for the tenant mentioned previously. They are in format of:

<domain>-tenid.xml – holds encrypted Tenant ID

<domain>-appsec.xml – holds the encrypted application secret of the Azure AD application for the tenant

<domain>.objid.xml – holds the encrypted Object ID of the Azure AD application for the tenant

<domain>.appid.xml – holds the encrypted Application ID of the Azure AD application for the tenant

Storing these details on a workstation is not the most secure option I agree, but it’s a starting point for what I’ll show you down track (read Azure Key Vault). However, because some people want the flexibility and simplicity of local files that’s where this starts.


If you examine one of these XML configuration files more closely, as shown above, you’ll see that the variable name (here AppSec) is stored in the Username field and the Password field has a long string of characters. You’ll notice that these characters actually don’t in anyway match the actual Appsec value that was captured earlier. That value was:


This means that the actual tenant variables save in the files are encrypted, so they can’t be easily recovered.


To get the unencrypted values back you’ll need to use the PowerShell import-clixml as shown above.


Well, you maybe thinking that it is easy enough to copy these configuration files to another PC and decrypt them there. Not so fast my sneaky friend, because the way these details are encrypted is that they are locked to just THAT machine and just THAT logged in user! As you can see from the above, if you try and decrypt these files with another user on that same PC or on another machine, you can’t.

All of this comes about because of the use of the export-climxl command to save the variables, which says:

The Export-Clixml cmdlet encrypts credential objects by using the Windows Data Protection API. The encryption ensures that only your user account on only that computer can decrypt the contents of the credential object. The exported CLIXML file can’t be used on a different computer or by a different user.

That’s why you needed to do that CTL+V paste command for each variable previously so that the variable could be saved as a credential object and take advantage of this encryption process.

This has now achieved STEP 1 in the process I spoke about initially to allow secure access to multiple tenant using the Microsoft Graph.


So what does the program actually do to each tenant behind the scenes? It is easy to see. Simply visit the Azure AD Directory location in the Azure portal for that tenant. If you then select the App registration from the menu on the left, and ensure you are viewing All Applications, you should see the application with the name you entered displayed on the right as shown above. Here, ciaops.


If you select the application name to get more details you’ll many of the variables saved to XML files as shown above.


If you then select API permissions on the left you will see that, as yet, no permissions have been given to this Azure AD Application (although they will be in an upcoming article).

However, we are not quite done yet as I have also created a program that will remove all of these Azure AD applications created quickly and easily. To do that download the program:


You need to place it into the directory where all the tenant configuration file are located as shown. Double click the program to run.


To remove that Azure AD application you’ll need to log back into every tenant interactively as shown above. You’ll see the same of the tenant that it wants credentials for in the program flow.


Once you have provided access to the tenant, the Azure AD application will be deleted along with the configuration files. You’ll then be take to the next tenant and asked to repeat the process.


Once there are no more configuration files found the program will end.

Remember, this program will delete every matching tenant it finds configuration files for in the current directory. If you only want to delete a subset of the total tenants you have configured, move the other configuration files out of the current directory until this process is complete.

In summary then, the programs that I have created and made available for free will create a ‘static’ Azure AD application in all the tenants you select. The idea in upcoming articles will be to show you how this ‘static’ embedded Azure AD application can now be used to report and potentially change the configuration of multiple tenants quickly and easily. I also provided a program to also remove all these Azure AD applications from tenants.

Next step will be to give the Azure AD applications appropriate permissions and then get some information from the tenants WITHOUT the need of manually logging into each.

Full Azure AD P1 is coming to Microsoft 365 Business


One of the frustrating things about Microsoft 365 Business was that it didn’t include the full Azure AD P1 feature set. It had about 80%. This unfortunately created a lot of confusion for people to know exactly was and was not included. For example, Dynamic Groups WAS part of Azure AD P1 but NOT part of Microsoft 365 Business.

That was until now! Per the above Message Center notification, Microsoft 365 Business will receive the full Azure AD P1 from April 2020! Seems like all of us (including Alex Fields, got our Christmas wish)

Thanks Microsoft, that’s going to make things much easier.

Secure logging with Microsoft 365 presentation

Here’s the slides from my longer presentation today at Ignite Copenhagen

Securely logging to Microsoft 365

Getting access to your information in Microsoft 365 starts with logging in but is it secure as it could be? Understanding security options at the point of entry like MFA, Legacy Authentication and Conditional Access on all devices is critical to keeping information protected as it is not only you that is trying to log into your account these days! Learn what security technologies you can add at login and the best practices approaches to configuring and monitoring these. Security starts  at the doorway to Microsoft 365 and simple configurations can greatly reduce your risks of unauthorised access. Come and learn what can be done.

Moving to the Cloud–Part 3

This is part 3 of a multi part examination of moving to the Microsoft cloud. If you missed the first episode, you’ll find it here:

Moving to the Cloud  – Part 1

which covered off setting up a site to site VPN to Azure and

Moving to the Cloud – Part 2

which looked at creating traditional ‘dive mapped’ storage as PaaS.

It is now time to consider identity. We need to know where a user’s identity will live in this new environment because there are a few options. Traditionally, a user’s identity has lived on premises in a local domain controller (DC) inside an Active Directory (AD). With the advent of the cloud we now have Azure Active Directory (AAD) as an option as well. It is important here to remember that Azure Active Directory (AAD) is NOT identical to on premises Active Directory (AD) per:


What this means is that native Azure AD (AAD) can’t do some things that on premises Active Directory (AD) can do. Much of that is legacy services like Group Policy and machine joins, etc. You’ll see that Windows 10 machines can be joined to Azure AD (AAD) directly but legacy systems, like Windows 7, 8 and Windows Servers can’t be directly joined to AAD. That’s right. As we stand today, even the latest Windows Server cannot be directly joined to AAD like it can be joined to an AD on premises.

Thus, if you have legacy services and devices as well as Windows Servers you want to remain as part of your environment, you are going to need to select an identity model here that supports traditional domain joins. I will also point out that, as of today (changing in the future), if you want to implement Windows Virtual Desktop (WVD), you will also need a traditional AD to join those machines to. However, if you have no devices that require legacy services, for example if your environment is totally Windows 10 pro based with no servers (on prem or in Azure IaaS), then all you will need is Azure AD.

Thus, not every one can jump directly to AAD immediately. Most will have to transition through some form of hybrid arrangement that supports both AAD and AD in the interim. However, most transitions are ultimately aimed at eliminating on premises infrastructure to limit costs such as patching and updating things like physical servers. This will be what we are aiming for in this scenario.

In a migration from a traditional on premises environment with a domain controller (DC) and AD we now have a number of options when it comes to identity in the cloud.

1. You can maintain the on premises domain controller and AD, while using Azure AD Connect to synchronise (i.e. copy) the user’s identity to the AAD. It is important to note here that the identity in Azure is a COPY and the primary identity remains on premises in the local AD. This is still the case if you implement things like password write back that are part of Azure AD P1 and Microsoft 365 Business. Having the user’s primary identity still on premises means this is where you need to go to make changes and updates.

2. You can swing the domain controller from on premises to Azure IaaS. This basically means setting up a new VM in the Azure VNET that has been created already, joining it to the existing on premises domain across the VPN, then using DCPromo to make it a domain controller. To make it the ‘primary’ domain controller, you swing across the domain infrastructure roles via the following in PowerShell:

Move-ADDirectoryServerOperationMasterRole -Identity “Target-DC” -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator

and then DCPromo the original on premises domain controller out and then remove it altogether. This way you now have your Domain Controller and AD on the VM in Azure IaaS working with machines in the Azure VNET and on premises thanks to the site to site VPN established earlier (told you it would be handy!). In essence, this is like picking up the domain controller hardware and moving it to a new location. Nothing else changes. The workstations remain on the same domain, group policy is unaffected, etc, etc. The downside is that you still need to continue to patch and update the new domain controller VM in Azure but the maintenance and flexibility is superior now it is in Azure IaaS.

3. You replace the on premises domain with Azure AD Domain Services. Think of this like a cloud domain controller as a service. It is a Domain Controller as PaaS. This means that when you use Azure AD Domain Services Microsoft will spin up two load balanced domain controller VMs and connect this directly to AAD so the users there now appear in the PaaS domain controllers. Using Azure AD Domain Services removes the burden of you having to patch, update, scale, etc domain controllers for your environment. It also gives you a traditional AD environment you can now connect things like servers to. However, there are some trade offs. When you use Azure AD Domain Services you must start a new domain. This means you can’t swing an existing domain across onto it, like you can in step 2 above. This means detaching and reattaching all your legacy devices, like servers, from the original to new domain. You also get limited functionality with traditional AD services like Group Policy. You should see Azure AD Domain Services as a transitionary step, not an end point.

With all that in mind, you need to make a decision on what works best for your environment, now and in the future. Considering that most environments I see want to eliminate the on premises domain controller hardware as soon as possible and not replicate this going forward. That desire therefore means a migration to PaaS using Azure AD Domain Services.

The first step in this process then is going to be to ensure that all your users are in Azure AD. The assumption here is that you have already set up your Microsoft 365 environment and the users are configured in Azure AD. If you retaining an on premises domain controller you’ll need to have set up Azure AD Connect to copy the user identities to Azure AD. Azure AD is where Azure AD Domain Services will draw it’s identities when it is installed, so the users need to be there first. Once the users appear in Azure AD, next step will be to set up Azure AD Domain Services. You can kind of think of a traditional on premises domain controller as somewhat being equivalent to Azure AD combined with Azure AD Domain Services.

Setting up Azure AD Domain Services is done via the Azure portal.


Login as a global administrator and locate Azure AD Domain Services and select that.


You’ll most likely find that no services are as yet configured. Select the Add option from the menu across the top as shown above.


You then need to complete the details. Here we face an interesting question, what should we call this new ‘traditional’ managed domain we are about to create with Azure AD Domain Services? Should it be the same as what is being used in Azure AD already?



How you configure this is totally up to you. There is guidance, as shown above, which can be found at:

Active Directory: Best Practices for Internal Domain and Network Names

In this case I have decided to go for a sub-domain, as recommended, and prefix the new Azure AD Domain Services with the letter ‘ds’ i.e.


With all the options completed, select Next – Networking to continue.


Unfortunately, you can’t configure Azure AD Domain Services on the same subnet that has service endpoints as you can see above. You’ll see this if you configured your Azure storage to use private endpoints as we have, which has been previously recommended.

If so, then you can select the Manage link below this box and simply add a new subnet to your Azure VNET and then use that to connect Azure AD Domain Services to.


Before you continue to Administration, ensure that you are adding Azure AD Domain Services to your existing Azure VNET as the default is to create a new VNET, which is NOT what you want here. You want to connect it to an existing VNET you have established previously.

When you have selected your existing Azure VNET and a suitable subnet, select the Next – Administration button to continue.


Here you’ll need to decide which users will be administrators for the domain.  So from the documentation:

What can an AAD DC Admin do?

Only Microsoft has domain admin and enterprise rights on the managed domain. AAD DC Admins can do the following:

  • Admins can use remote desktop to connect remotely to domain-joined machines

  • Admins can join computers to the domain

  • Admins are in the administration group on each domain-joined machine

Considerations for the AAD DC Administrators group

  • Pick group members for the AAD DC Administrators group that have these needs:

    • Users that need special administrative permissions and are joined to the domain

    • Users that need to join computers to the domain
  • Do not change the name of the AAD DC Administrators group. This will cause all AAD DC Admins to lose their privileges.

The default will be your global administrators and members of a special group called AAD DC Administrators, that will be created. So, you can simple add any Azure AD user to this group and they will have admin privileges in the  Azure AD Domain Services environment going forward.

You can of course configure these permissions any way you wish but generally the defaults are fine so select the Next – Synchronization button to continue.


The final question is whether you wish to have all or a subset of your Azure AD users synchronised into the Azure AD Domain Service environment. In most cases, you’ll want all users, so ensure that option is select and press the Review + create button to continue.


You should now see all your settings and importantly, note the box at the bottom about consenting to store NTLM and Kerberos authentication in Azure AD. This is because these older protocols have potential security concerns and having them stored in a place other than a  domain controller is something you need to be aware of. Generally, there won’t be any issues, but make sure you are aware of what that last box means for your security posture.

Press the Create button when complete.


You’ll then receive the above warning about what configurations options can’t be changed after the fact. Once you have reviewed this and you wish to proceed, select the OK button.

Your deployment into Azure will then commence. This process should generally take around 1 hour (60 minutes).


You should see the above message when complete and if you select Go to resource you’ll see:


You’ll note that it still says Deploying here, so you’ll need to wait a little longer until that process is complete.


In about another 15 minutes you should see that the domain is fully deployed as shown above. Here you will note that two domain controllers have automatically been allocated. In this case they are and on the subnet into which Azure AD Domain Services was deployed. You can select from a number menu options on the left but the service is pretty basic. Most times you’ll only need to look at the Activity log here from now on.

Can you actually manage the domain controllers like you can on premises? Yes, somewhat. To do that you’ll need to download and install the:

Remote Server Administration Tools for Windows 10

on a Windows 10 workstation that can access these domain controllers.


You can then use that to view your domain in the ‘traditional way’ as shown above.

Thus, with Azure AD Domain Services deployed, you have a ‘traditional’ domain but without infrastructure and with your Azure AD users in there as well.

The summary of the options around identity here are thus:

1. Primary = local AD, Secondary = none (which can be linked to Azure via a VPN)

2. Primary = Azure AD, Secondary = none (no on premises infrastructure like servers to worry about)

3. Primary = local AD, Secondary = Azure AD (thanks to Azure AD Connect, but need a VPN again to connect to Azure IaaS)

4. Primary = Azure AD, Secondary = Azure AD Domain Services (which can be linked backed to on premises via a VPN)

In this case, we’ll be going with Option 4. You can see however that a VPN is going to be required for options 1, 3 and 4. That’s why one of the first steps in this series was to set one up.

With all that now configured, let’s now look at the costs involved. The costs here will vary on what identity solution you select. If you stay with an on premises domain controller only, you will need to have site to site VPN to resources in Azure. The costing for this has been covered previously:

Moving to the Cloud  – Part 1

and equates to around AU$36 per month with less than 5GB of traffic inbound to Azure. Azure AD Connect software you use to synchronise user identities to Azure AD is free.

If you move the domain controller to a virtual machine in Azure, there will be the cost of that virtual machine (compute + disk storage). The cost will therefore vary greatly on what VM type you select. I’ll be covering more about VM options in this migration in an upcoming article, but for now let’s keep it simple and say we use a A2v2 Standard VM (4GB RAM, 20GB HDD) for a single role as just a domain controller. The cost for that is around AU$76 per month. If you also still have on premises infrastructure, like Windows Servers, that need access to the domain, then you’ll also need a site to site VPN to communicate with the domain controller VM in Azure IaaS. Thus, to move the domain controller to Azure IaaS and still allow access to on premises infrastructure the cost would be around AU$112 (Azure VM + VPN). Of course, if you can migrate all your on premises server infrastructure to Azure IaaS, you probably wouldn’t need the VPN but there would then be the costs of the additional infrastructure in Azure. Balanced against this cost in Azure IaaS is the saving in local hardware, power, etc.

Again, let’s keep it simple for now and say we want to maintain on premise infrastructure but have a dedicate domain controller in the Azure IaaS so the one on premises can be de-commissioned. That means the costs would be AU$112 per month for a domain controller in Azure IaaS and a VPN back to on premises.

Finally, the last identity option is if we wanted to use the Azure PaaS service, Azure AD Domain Services, which means no infrastructure at all but also means we need to start with a new ‘clean’ domain separate from the existing on premises one. The costs of this Azure PaaS service can be found at:

Azure Active Directory Domain Services pricing

which reveals:


For smaller directories (<25,000 objects) the cost is going to be AU$150 per month flat. Remember, here when equating costs, there are no VMs to backup or operating systems to patch because it is PaaS. This is a domain controller as a service and Microsoft will take care of all the infrastructure “stuff” for you as part of that service. Of course, if you need on premises infrastructure to access Azure AD Domain Services, you’ll again need a site to site VPN to get there. If all your infrastructure is cloud based, then no site to site VPN is required. However, in this scenario, we still want access to on premises infrastructure so the costs would be AU$186 per month (Azure AD Domain Services + VPN).

In summary then, the configuration options/costs will be:

Option 1. Retain on premises AD = AU$36

Option 2. Move domain controller to Azure IaaS = AU$112 (estimated typical cost)

Option 3. Migrate domain controller to Azure PaaS = AU$186 per month

Going forward we’ll be selecting Option 3, because we are aiming to minimise the amount of infrastructure to be maintained and we want to move to PaaS as soon as possible. That means the total cost of the migration so far is:

1. Site to Site VPN = AU$36

2. Storage = AU$107

3. Identity (PaaS) = AU$150

Total maximum infrastructure cost to date = AU$293 per month

This means we have:

1. Eliminated the old on premises domain controller (hardware, patching, backup, power, etc costs)

2. Can connect to on premises infrastructure to Azure AD (via Azure AD Domain Services and the VPN)

3. Have mapped tiered storage locations for things like archiving, profiles, etc that are PaaS

4. We can now build out a Windows Virtual Desktop environment

The next item that we’ll focus on is setting up a Windows Virtual Desktop environment as we now have all the components in place to achieve that.