It’s been a minute…

I thought I’d take a few minutes to document a process I’ve developed that forms part of my productivity flow within Obsidian. For those of you unfamiliar, Obsidian is a personal knowledge base and note-taking application - similar in nature to OneNote, Evernote, Notion etc. I’ve become a huge fan over recent weeks, moving my entire note-taking workflow to it in place of various other - often disparate - methods of tracking my thoughts, actions, and musings across my work and personal life. There are lots of things behind this decision; the way it supports organic and simple linking of thoughts and topics, the ease with which you can search and sort your notes, it’s extensible nature, the use of markdown as a primary input format etc. etc. - but fundamentally it just ticks all of my current boxes where others don’t… all that is, except for one! 🙂

So what’s the issue?

To explain my predicament, I first need to explain a little about the way that Obsidian stores note content. Each time you create a note, a new markdown file is created based on the title. This is stored in a file structure that Obsidian refer to as your “vault”, which is ultimately just a folder structure in a location on your device that mimics that which you build out in the Obsidian application. For the most part this structure is largely irrelevant - the magic of discovering / searching / linking your content is in the way you leverage tags and links within your note metadata and content - but it does serve the nice purpose of being non-proprietary. At any point you could do away with Obsidian and still have access to all of your notes in a reasonable structure. This is great - and also enables the use of various cloud sync services (e.g. OneDrive, Google Drive, Dropbox etc.) to synchronise your note content into different installations of Obsidian across your devices; providing flexibility and reassurance that your data is securely stored and always available. I do exactly this, storing my vault in OneDrive for Business, and also making use of a Community Plugin to push my content into a GitHub repository for version history and a tertiary copy of my data (local, OneDrive, and GitHub).

So what’s the catch? Well, this comes when you start to consider when and how you capture those incidental and sometimes random “things” that you want to drop into a note to refer to or action later, but where you may not have access to your Obsidian vault. How often do you pull up the Notes app on your phone, or find yourself simply emailing yourself a URL to an article to read later? This is a common requirement for most of us… particularly in the context of “Personal Knowledge Management” (PKM) workflows. It’s also one that is bizarrely difficult to integrate with Obsidian given the “local” nature of the Obsidian Vault.

Now, there is a mobile Obsidian app. Why not use this? Well, there’s a further constraint here in that (specific to iOS, but I believe also relevant to Android) to sync to mobile you are required to subscribe to Obsidian Sync - a premium sync service that costs £7.99 per month. I’m the first to invest in and support subscription services that I believe add value to my life… but I’ll be damned if I’m going to pay an amount equivalent to Netflix / Disney+ / Amazon Prime for a very occasional scenario that’s often better served with a quick email “note to self”.

OK, so what’s the fix?

The fix for me involves a relatively simple bit of Power Automate. Similar workflows are alluded to regularly on the Obsidian forums, but I struggled to find a decent and up to date summary of the steps involved, so cobbled together a Flow of my own to address my use case. Hopefully this write up saves someone else an hour or two of jiggery pokery down the line. A screenshot of the Power Automate can be found towards the end of this post, the actions taken are as follows:

1. Step 1 is the trigger, initiating the Flow when an email is received that meets specific criteria. I’m taking advantage of “Plus Addressing” (a topic I’ve blogged about previously, see here) to tag specific emails for processing by the Flow - “myemail+obsidian@kelvinpapp.com”. The trigger is also scoped to only fire on emails received from my work, or personal email addresses.

2. Steps 2 & 3 process the email, marking it as read and then moving it to my archive (once it’s added to Obsidian, I no longer have a need for the email… I’ve always worked on the premise that mail in my inbox is either unread or requires a follow up, everything else is deleted or archived).

3. Step 4 takes the email body and converts it to plain text, ready for saving as a markdown file within the folder structure of my Obsidian Vault. There are some quirks with this function which account for steps 5-7 - additional line spaces are inserted when a double line space is present in the original email. This irritates me, so steps 5 and 6 define double and single space variables respectively, before step 7 uses a “replace” function to identify these in the plain text output of step 4 and correct them. The replace expression used is as follows:

replace
(outputs('Convert_Email_to_Plain_Text')?['body'],
variables('Double Space'),
variables('Single Space')
)

4. Step 8 defines a variable for the markdown output which we populate in step 9. Step 9 is a condition which addresses another nuance of my setup depending on whether the original email has come from my personal, or corporate email account. In the case of the latter a signature is appended which I remove using another expression, this time a “split” function which looks for the start of my signature and only takes the text before that point. The split expression used is as follows:

split(outputs('Remove_Double_Line_Spacing'),'Kelvin Papp')[0]

5. The output of the condition is the “setting” of the output variable initialised in step 8. This is subtly different on either side of the condition - taking the direct output of step 7 in the case of my personal email, or the output of the split function above if the email has come from my corporate address. In both cases I also append some default frontmatter which I use subsequently in Obsidian:

---
Created: dd MMMM yyyy HH:mm (based on the email received time)
From: Recipient Email Address (taken from the original email)
Tags: Work, Personal, Email/New
---

6. Finally, step 10 creates a markdown file using the name “Subject.md” (where the subject line is taken from the received email), and using the output variable defined in the steps above. This (the final bit of magic, and possible based on the flat file nature of Obsidian) is saved into the OneDrive for business folder used for my Obsidian Vault, in a dedicated “Email Notes” folder.

Power Automate Flow

Summary

…and that’s all there is to it! In a few (fairly) simple steps you can now email anything you like to yourself and have it appear automatically within Obsidian as a new note, complete with bespoke frontmatter to help you with identification and organisation of “incidental” notes or information you wanted to send to your future self! I find this super useful, and infinitely quicker and easier than trying to navigate a third-party notes application on my phone (assuming that was even possible without a separate subscription). I hope you do too…

As usual, feel free to get in touch with any questions or feedback. Hopefully more (potentially Obsidian related) content to follow very soon!

It’s been a while! I first started drafting this post late last year following a discussion with a colleague at work about how useful I find this feature… only to discover it was a total revelation to the person I was speaking with. Having drafted around 80% of what you see below I held back on finishing it after having my own revelation; the post was pretty dull 🙂 Fast forward though and there have been some developments that make finishing that final 20% worthwhile…

Plus Addressing is one of those nifty features that you’ve either never heard of, or know all about and absolutely love. For those unaware plus addressing allows you route custom variations of your primary email address without the need for the creation of specific aliases - enabling you to create and issue bespoke addresses on the fly that you can subsequently track and take action against. Take the simple example of signing up to an online newsletter. Do you know that your email address won’t be sold on to a third-party? Are you confident that unsubscribing will actually lead to your address being deleted or no longer used? Do you want to easily hive those communications off to a folder for later review? By using a custom email address you can regain some control; tracing the source of spam email or implementing rules to filter out or delete ongoing and unwanted use. Typically this requires administrator intervention to define and add the SMTP alias to a mailbox. Plus addressing negates the need for this - allowing you to take control of implementing inbound address variations as and where you see fit.

It’s been a standard feature for Gmail users for years - back in my Gmail days I’d use it routinely when signing up to third-party websites. Usage is simple; append whatever you want between the username and “@” portion of your email address using a “plus” (+) symbol. For example “joe.bloggs@domain.com” might choose to provide “joe.bloggs+retailername@domain.com” as their email address. This would be delivered as normal but the “plus” portion of the address would remain visible, enabling a range of things such as:

• Automatic routing to folders using mailbox rules,
• Visibility in the event an address being (maliciously or otherwise) passed to a third-party,
• Automatic deletion if use of the address becomes a source of frustration etc.

In many respects plus addresses operate much like mailbox aliases but with the advantage of not needing to be created in advance. You can’t send from them - worth noting if you intend to use them to subscribe to mailing lists that require outbound email validation, or have other requirements that need you to present on the address. For this you’ll need to rely on traditional aliases and the recently announced (preview) support for sending from these. You can discover more detail on this functionality in Sending From Email Aliases – Public Preview.

What’s the history with Plus Addressing and Exchange Online?

Plus Addressing has been available in Exchange Online since late 2020, but there’s been a catch. The use of the “+” symbol is permitted within the various RFCs that underpin email address formatting (RFC2822 / RFC5322 / RFC6854) and has been supported by Exchange in the context of mail aliases for a number of years as a result. Microsoft’s stance has been to make the feature opt-in with guidance to remove any existing “+” objects from mail aliases when you do to mitigate potential mail routing issues.

For those that wanted to opt-in, the way to do so was to enable the feature via a single PowerShell command:

Set-OrganizationConfig -AllowPlusAddressInRecipients $true

What’s changing?

Microsoft’s approach to Plus Addressing is changing. Announced last year the feature will become opt-out instead of opt-in. A Message Centre update this weekend confirmed the timescales for this change with all tenants due to enabled by default during April and May. For some organisations - notably those with hybrid mail deployments and a heavy use of “+” characters in mail addresses and aliases - this introduces an element of risk. This risk is summarised in the below statement from Microsoft (taken from Plus Addressing in Exchange Online):

This feature was rolled out behind a setting because, historically, customers have been able to use plusses in addresses for mailboxes in Exchange Online and on-premises servers. When this feature is enabled, Exchange Online will first check if the full address can resolve to a mailbox that the service is aware of. It is only when that resolution fails, that a plus is looked for and a second attempt to resolve the address without the plus and tag is done. This means that the feature is compatible with addresses containing plusses that Exchange Online knows about. If you relay messages to a mailbox on-premises that does not resolve in Exchange Online, message delivery will be affected. The messages will be parsed and addressed to the parsed address for example, sean@contoso.com instead of the full sean+newsletter@contoso.com, using the example above.

The “-AllowPlusAddressInRecipients” setting is being deprecated and replaced with a new setting which can be configured to prevent Plus Addressing functionality. If you wish to prevent Plus Addressing from being used in your organisation it’s important you run the following command in your tenant in advance of April:

Set-OrganizationConfig -DisablePlusAddressInRecipients $true

Summary

For many organisations Plus Addressing is a neat bit of functionality that - with some minor user training and awareness - can add a great deal of end-user value. It’s not without risk though and it’s important that you understand the potential for issues if you have complex routing scenarios or a legacy of “+” symbols in your addresses. You can read more in the link I posted above.

In other news… it’s good to be back 🙂 Social media and blogging tends to take a back seat when things get hectic. I’d forgotten how enjoyable it is to get your head into something and play it back to (hopefully) benefit others… feel free to get in touch with any questions or feedback.

One of the announcements from Inspire this week that has everyone talking is, of course, Windows 365. What is it? Where does it fit? What about Azure Virtual Desktop? Just some of the many questions I’ve seen raised, and received directly in the last few days. It’s an exciting launch – one that dramatically simplifies the approach towards Cloud Desktop for many organisations – but one that also raises questions in terms of its positioning, and its general suitability against certain use cases. Whilst the detailed technical information on Windows 365 is still sparse, there is some detail working its way through. I thought I’d take the chance to summarise what we know so far and tackle some of these questions. This won’t be close to exhaustive (and subject to change pre-release on August 2nd)… but it should help to address some of the initial things you may find yourself questioning…

So what is it?

At its core, Windows 365 is another form of Desktop as a Service - iterating the previous move by Microsoft into this space with what was Windows Virtual Desktop (WVD) - now Azure Virtual Desktop (AVD). It’s built on much of the same architecture but operates on a fixed (with some caveats) price per month vs. the consumption based model applied to AVD. I’ve written about AVD before, and covered off some of the long history I’ve had with various Remote Desktop and VDI solutions in general. The way the market for this type of technology continues to reinvent itself to address the needs of users and business is something I find fascinating, but I can’t argue with the need. In spite of an underlying shift to “cloud-native”, centralised / hosted / managed desktops (whatever term you prefer) have a place. Not only this, but advances in connectivity and technology have the potential to make this way of working more seamless than ever before.

Windows 365 is published in the same way as AVD so accessible across devices and platforms (Windows, MacOS, Linux, Android and iOS) using a combination of clients, apps, and browsers. You’ll be able to subscribe to either a Business or Enterprise Windows 365 desktop in a variety of VM sizes as outlined in Christian Brinkhoff’s excellent blog post on the Tech Community:

In terms of key differences to AVD (beyond the charging model):

• The subscription and related Azure services are managed by Microsoft
• Desktops are dedicated to the user (there’s no concept of a multi-session / pooled desktop)
• Profiles are local (save OneDrive redirections), no FSLogix support
• Monitoring is limited to Endpoint Analytics and in-guest / agent based alerting
• Backup is restricted to in-guest agent based solutions, or redirection (e.g. ODfB)
• Sizing is restricted to specific CPU / RAM combinations

These differences are unsurprising in many respects… it’s more of a “Managed Service” than AVD, and there are constraints on access and management as a result. The more important distinctions come when you start to look at the differences between the Business and Enterprise editions of Windows 365:

Business Windows 365 Desktops:

• Are provisioned as Azure AD joined VMs
• Cannot be integrated with an Azure or on-premises network
• Need to be managed like standalone desktop endpoints
• Are limited to 300x endpoints per organisation

Enterprise Windows 365 Desktops:

• Are attached to customer managed Azure VNets at the point of deployment
• Are provisioned as hybrid joined VMs
  • The virtual network specified must have sight of Active Directory
  • Users must be synchronised between AD & Azure AD
  • Azure AD Domain Services is not supported (Active Directory only)
• Can access corporate applications in Azure / on-premises (subject to Azure networking)
• Connect to the internet via the customers Azure subscription (egress charges apply)
• Require the assigned user to be licensed for Endpoint Manager
• Are enrolled into and managed by (patching, application deployment etc.) Endpoint Manager
• Require an Endpoint Manager license to be assigned to each user allocated a desktop

The two flavours are very different in terms of pre-requisites, capability, and configuration, and further still from AVD. There are some important questions to ask when determining which is right for you:

• Is corporate application access required?
• Do you use traditional Active Directory, or Azure AD only?
• Is the storage of desktops outside of your own Azure tenant an issue?
• Are you looking for cost-benefits associated with pooled desktops, out-of-hours shutdown, or Reserved Instances?
• How important is centralised management of your desktop and applications?
• Does you require host-level management of the underlying VMs?

Summary

There’s obviously much more to come on Windows 365, so any judgment or opinion now is likely to change. As it stands I find the release really exciting (a viable alternative to AVD which is highly attractive to organisations who just want simplicity), yet also slightly frustrating… Why the need for hybrid join in Enterprise? Why no support for Azure AD Domain Services? Why no VNet integration for Business Desktops? I appreciate the need for distinction, but the feature mapping seems off to me when I consider the sorts of use cases we will encounter at Transparity. As was the case with A(W)VD, I’m confident we’ll see rapid progress when it comes to features and functionality… I’m just a little impatient!

A side note, but I’m not the only one excited for native Azure AD join (preview) in AVD, right?! 🙂

Another slightly left-field post from me today, which follows directly from my previous post. Since transitioning the blog to Hugo, social sharing hasn’t been working in quite the way it should. I noticed this after sharing a link on Twitter only to find that the Twitter Card didn’t render in the way I’d become used to with WordPress. I’ll be honest, I’ve never really given any thought to how this works, assuming that this is just “native in the way various social media platforms interpret links. It turns out there’s actually (and perhaps unsurprisingly) a host of things that influence the format and content that gets pulled, all of which are done for you when you use a platform like WordPress (with a decent theme). Cue a lazy Saturday morning, the rabbit trail that is the internet, and I’m now much more informed.

I thought I’d take a moment to document my findings in the hope that it helps someone else down the line.

It’s all about the Meta…

The net result of my findings is that meta tags are all important. When you post a link to Twitter, LinkedIn, or various other sites there are attributes those sites look for that define how the media should be displayed. These are often (although not in all cases) based on the common “Open Graph” protocol, allowing developers to use a single set of “standard” properties that work consistently across different social platforms. These attributes set out the important characteristics of the media; the title, description, type of content, image that should be displayed, source URL etc.

That nice thumbnail and detail that gets generated when you post a link on LinkedIn or Facebook? That’s Open Graph in practice and you’ll see it used almost ubiquitously.

Take the (slightly edited) example below from BBC News:

<meta property="og:title" content="Home - BBC News">
<meta property="og:type" content="website">
<meta property="og:description" content="Visit BBC News for up-to-the-minute news, breaking news, video, audio and feature stories.">
<meta property="og:site_name" content="BBC News">
<meta property="og:locale" content="en_GB">
<meta property="article:author" content="https://www.facebook.com/bbcnews">
<meta property="article:section" content="Home">
<meta property="og:url" content="https://www.bbc.co.uk/news">
<meta property="og:image" content="https://m.files.bbci.co.uk/modules/bbc-morph-news-waf-page-meta/5.1.0/bbc_news_logo.png">

Some sites - Twitter being a prime example - have their own requirements. These allow further customisation of the way that media is presented. In the case of Twitter, “Cards” are used which are rendered based on proprietary meta tags. In some cases Twitter make use of Open Graph tags to assume content for these (saving the need to double up on tags, see here) but this isn’t always the case so you will often see Twitter specific tags listed alongside Open Graph metadata in source code.

The below extract is taken from the same BBC News page used above:

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@BBCNews">
<meta name="twitter:title" content="Home - BBC News">
<meta name="twitter:description" content="Visit BBC News for up-to-the-minute news, breaking news, video, audio and feature stories.">
<meta name="twitter:creator" content="@BBCNews">
<meta name="twitter:image:src" content="https://m.files.bbci.co.uk/modules/bbc-morph-news-waf-page-meta/5.1.0/bbc_news_logo.png">
<meta name="twitter:image:alt" content="BBC News">
<meta name="twitter:domain" content="www.bbc.co.uk">

Why are these tags important? Well without them you can get some “odd” behaviour when posting links. In some cases you’ll see a basic interpretation of the link content in a vanilla format. Worst case you may find that content doesn’t present as a “media” entry at all - just an ugly, naked URL.

We all know and appreciate the importance of getting this right on social media. In a world of swiping and scrolling not standing out can be the difference between your content being noticed or not…

So how does Hugo handle metadata for link sharing?

I mentioned above that some platforms, like WordPress, take care of meta tagging for you. This is also true of static site generators like Hugo, however the additional (relative) complexity of these solutions vs. “do it for you” services introduces margin for error and puts more emphasis on understanding how this metadata is generated in the background. For the most part with Hugo, metadata is generated based on the Front Matter defined in your input content and couples this with internal templates (not theme specific) to convert this into the required properties for social sharing.

Let’s look at some of the key properties needed to make this work “elegantly” with Twitter cards and the Hugo properties that feed them, specifically the “Summary Card with Large Image” option which provides the most prominent summary for Twitter sharing:

• Title: Generated from the post name, typically set with the “title” property in front matter
• Description: Automatically generated based on the post content, or set manually using th “description” property in front matter
• Site: The Twitter user associated with the content, best set in the config.toml file (.Site.Social.twitter)
• Image: The thumbnail to be used when sharing (required to use the “card with large image” option)

It’s worth referring to the internal template (twitter_cards) used to generate Twitter metadata which can be found here to explain some of these properties and how they are used in more detail:

{{- with $.Params.images -}}
<meta name="twitter:card" content="summary_large_image"/>
<meta name="twitter:image" content="{{ index . 0 | absURL }}"/>
{{ else -}}
{{- $images := $.Resources.ByType "image" -}}
{{- $featured := $images.GetMatch "*feature*" -}}
{{- if not $featured }}{{ $featured = $images.GetMatch "{*cover*,*thumbnail*}" }}{{ end -}}
{{- with $featured -}}
<meta name="twitter:card" content="summary_large_image"/>
<meta name="twitter:image" content="{{ $featured.Permalink }}"/>
{{- else -}}
{{- with $.Site.Params.images -}}
<meta name="twitter:card" content="summary_large_image"/>
<meta name="twitter:image" content="{{ index . 0 | absURL }}"/>
{{ else -}}
<meta name="twitter:card" content="summary"/>
{{- end -}}
{{- end -}}
{{- end }}
<meta name="twitter:title" content="{{ .Title }}"/>
<meta name="twitter:description" content="{{ with .Description }}{{ . }}{{ else }}{{if .IsPage}}{{ .Summary }}{{ else }}{{ with .Site.Params.description }}{{ . }}{{ end }}{{ end }}{{ end -}}"/>
{{ with .Site.Social.twitter -}}
<meta name="twitter:site" content="@{{ . }}"/>
{{ end -}}
{{ range .Site.Authors }}
{{ with .twitter -}}
<meta name="twitter:creator" content="@{{ . }}"/>
{{ end -}}
{{ end -}}

Here, we can see exactly how Hugo generates the “twitter:” metadata, and how the decision is made as to which “card” type to use. This is based entirely on the presence of a suitable image which is identified by looking (in order) for the following:

1. A specified image, defined in the front matter as noted above
2. An image within the post content containing the word feature, cover, or thumbnail within the name
3. An image specified within the site configuration (i.e. the config.toml file defining global site properties)

If any of the above are identified, the “twitter:card” tag is set to “summary_large_image”. In all other scenarios, this is set to “summary” which is far less prominent…

In my case, I’d not specified any of these so when sharing a post on Twitter only the summary card template was being used. In addition, the Open Graph “image” property wasn’t set - so sites other than Twitter depending on this value to render “rich” content may also have failed. I say “may” because some sites (for example, LinkedIn) will render images present within a post if they aren’t set explicitly in metadata. This caused me some extra head-scratching yesterday when I was trying to get to the bottom of what was happening with this site…

I’ve since modified my “posts” archetype so that my front matter is pre-populated with an “images” option for me to specify… hopefully preventing me from forgetting in future (or needing to remember to name my post images in a certain way). I will also be setting a fallback image in my site configuration, just in case. An example of the front matter I’m now defining is as follows:

title: "Migrating the Blog to GitHub and Hugo"
author: Kelvin Papp
type: posts
date: 2021-03-23T20:05:45Z
draft: false
toc: false
images: 
  - /img/2021/03/Hugo-Logo-Social.png
url: /migrating-the-blog-to-github-and-hugo/
categories:
  - Azure
  - Personal
  - Microsoft
tags:
  - Azure
  - Hugo
  - Blog

This results in the following tag creation for those interested:

<meta itemprop="name" content="Migrating the Blog to GitHub and Hugo">
<meta itemprop="description" content="Ever since I started the blog (two years ago today as it happens!) I've been using self-hosted WordPress as my platform of choice...">
<meta itemprop="datePublished" content="2021-03-23T20:05:45+00:00" />
<meta itemprop="dateModified" content="2021-03-23T20:05:45+00:00" />
<meta itemprop="wordCount" content="1213">
<meta itemprop="image" content="https://www.kelvinpapp.com/img/2021/03/Hugo-Logo-Social.png">
<meta itemprop="keywords" content="Azure,Hugo,Blog," />
<meta name="twitter:card" content="summary_large_image"/>
<meta name="twitter:image" content="https://www.kelvinpapp.com/img/2021/03/Hugo-Logo-Social.png"/>
<meta name="twitter:title" content="Migrating the Blog to GitHub and Hugo"/>
<meta name="twitter:description" content="Ever since I started the blog (two years ago today as it happens!) I've been using self-hosted WordPress as my platform of choice..."/>
<meta name="twitter:site" content="@kelvinpapp"/>
<meta property="og:title" content="Migrating the Blog to GitHub and Hugo" />
<meta property="og:description" content="Ever since I started the blog (two years ago today as it happens!) I've been using self-hosted WordPress as my platform of choice..." />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://www.kelvinpapp.com/migrating-the-blog-to-github-and-hugo/" />
<meta property="og:image" content="https://www.kelvinpapp.com/img/2021/03/Hugo-Logo-Social.png" />
<meta property="article:published_time" content="2021-03-23T20:05:45+00:00" />
<meta property="article:modified_time" content="2021-03-23T20:05:45+00:00" />

Some useful tools…

I discovered, during my troubleshooting, that both LinkedIn and Twitter have validation tools which allow you to test how your media will present when used in posts on their sites… these are super useful and worth bearing in mind if you encounter issues like me…

They can be found as follows:

• Twitter Card Validator
• LinkedIn Post Inspector

I hope this helps someone… a niggly issue for sure, but if you’re at all like me it’ll drive you mad to see links being posted with inane “summary” cards on Twitter, or appearing elsewhere with random images associated (or perhaps none at all!)! All power to the meta!

Ever since I started the blog (two years ago today as it happens!) I’ve been using self-hosted WordPress as my platform of choice. This felt like a no-brainer at the outset - a platform I’d dabbled with in the past and used almost exclusively in the tech blog community. It’s well catered for; there are a multitude of plugins, some well structured and nicely designed themes, and plenty of resources to help you get up and running quickly. For the most part it’s served the purpose well. It’s not without fault though… and for some time now I’ve felt it might be time for a change.

I’ve written a little bit previously about how the site was configured (see here). In summary an Azure App Service, standalone MySQL Azure Database, SendGrid and - more recently - Azure CDN. This latter service has been subject to some change. Initially I served all content via the CDN (as per the blog post), but quickly ran into issues with caching when publishing new content. I eventually settled on a plugin to re-write image and theme URLs to the CDN - meaning generated page content was published direct via the Web App, and heavier content via the CDN. The net result of this was good; minimal maintenance, pretty reasonable performance, and a CMS in WordPress that was intuitive and (generally) reliable…

So why change?

Well… in short, the “good” hasn’t really lasted. I’ve found (increasingly) that site performance is mediocre. Page load times are pretty high (in spite of plenty of grunt on the App Service side), and no matter what database and image optimisation I’ve tried I’ve struggled to get things “snappy”. My Google Analytics stats back this up. WordPress is great, but a little “black box” at times which makes troubleshooting and performance optimsation a pain. Couple that with seemingly endless engine, theme, and plugin updates, and I’ve found I spend more time “tinkering” than I do thinking about content. Enjoyable as that sometimes is (the tinkering, that is!), it isn’t what I set out to do.

Alongside all of the above I’ve been aware that a growing number of sites I follow have been moving to alternative platforms. In many cases, for reasons much like my own.

There’s been a growing “buzz” around static site generators (SSGs) which provide many of the benefits of CMS systems like WordPress (e.g. extensive theme libraries which can be applied “dynamically” to static content), but without the performance or maintenance overhead of a full blown CMS. You’ve likely heard of some of these… Jekyll, Gatsby, and Hugo are some popular examples.

What is a Static Site Generator?

The concept is simple. You input your content - usually in the form of markdown files that define the high level structure and layout - and you process these using your SSG of choice, in accordance with a site configuration file. This configuration file tells your SSG what to do; what theme to apply and how to define certain site settings - date / time format, theme specific variables, and global site information such as the base URL, title, author details and sharing options etc… These options are often theme specific, but highly configurable in much the same way as full blown CMS solutions like WordPress are (albeit via text input, vs. a nice GUI).

The end result is an output folder containing a dynamically generated static site that combines the layout you’ve defined, and the content you’ve created into a flat-file website. Want to write another post? All you need to do is upload a markdown file containing your content to the relevant folder, and reprocess. Upload the output to your hosting platform of choice, and you have a website that has many of the benefits of a dynamic site but coupled with those of a static equivalent… more secure (due to no database), better performing, and next to no “server” maintenance.

What have I done?!

Well, those of you who have visited before will already have noticed that the look and feel is slightly different. No, I haven’t just changed the theme. I’ve gone all in with the static site approach… as of a few days ago this site is no longer built on WordPress. All the content on this site is now generated via Hugo. I’m staggered at the performance improvement and the (relative) simplicity of the transition. Aside from some time tweaking embedded URLs and some formatting oddities of the markdown export tool I used against WordPress, the process couldn’t have been much easier.

It doesnt end there though. The observent of you will have clocked GitHub in the title. Where does that fit?

This, for me, is where the magic of Cloud services comes together. Using SSGs in isolation is quite cool… you can install locally and run the (in my case) Hugo process to generate content from, and to, a local folder. One of the things that tipped my decision to migrate though, was my discovery of the new(ish) Azure Static Web App service. Static Web Apps are a preview feature (and have the advantage of being free - for now) that integrate with GitHub repositories to automate the processing and delivery of web content based on common frameworks or static site generators… Hugo is one of these.

When you deploy a Static Web App, you connect it to a GitHub repository - telling it in the process which deployment framework your source repository uses. This creates an automation workflow in your linked repo, triggered whenever a Git commit is made that reprocesses the contents and uploads the revised content to your Web App. This enables updates from anywhere using a simple git push command! To top things off… you can also commit to a branch, initiate a pull request, and have your “staging” site provisioned into a separate envronment in your Web App. When the pull request is closed and the branch merged with main / master, the staging site is migrated into production. Magic!

I love this new workflow, and increasingly enjoy working with markdown files / git in my local editor… largely as a result of contributing more regularly to Microsoft Docs. There’s something about the simplicity of plain text and the process that feels efficient and (quite ironically) modern. Performance is fantastic, and I have full ability to test and revert changes as and when I need to.

You can read more about the process for integrating Hugo (and others) with GitHub and Azure Static Web Apps here, if interested.

Summary

I still have some work to do on the new format. There are some layout tweaks I want to make and some extensions I’d like to integrate to make interactions (both sharing, and commenting) a bit more “blog like”. Hopefully you’ll agree the new look isn’t too shabby though 👌 There’s no going back for me… What started out as a bit of a learning exercise to get more comfortable with GitHub has become a new way of creating content that I’m super happy with.

I’d encourage those of you wedded to CMS platforms to take a look. It may not be everyone’s cup of tea, but for me it’s a case of goodbye WordPress, long live GitHub and SSG!

Barely a day goes by without some form of Microsoft Cloud related announcement. We’ve come to accept that not only does Cloud move quickly, but that staying up to date is a constant battle. I find myself trawling various blogs, message centres, and Twitter accounts almost daily… Whilst these are pretty accessible to those that want to go digging for what’s new I’ve considered posting a periodic round up on here a few times - consolidating some of my own findings, and acting as a signpost for others looking to explore some of the key announcements.

So here goes… a round-up of a few of my key takeaways so far in February:

Microsoft 365

Microsoft Viva. What Microsoft blog worth its salt would let February pass without at least some reference to Viva, Microsoft’s new Employee Experience & Engagement platform?! I say platform, more suite of services given the spread of functionality across Topics, Connections, Learning, and Insights. Each of these is probably worthy of a post in itself. For now I’d encourage you to have a read of Microsoft’s “People Powered Workplace” e-book. It’s fair to say there’s an element of consolidation and rebranding at the heart of Viva, but I’m keen not to diminish the impact it’s likely to have. Information is lacking in some areas as things stand. More to follow soon.

The all new (well, mostly new) Microsoft 365 Security Center. A frustration for many has been the plethora of portals that need to be used for the management of M365. Security alone is (was) scattered across no less than 4. No more. Defender for Endpoint, Microsoft 365 Defender, and a number of other controls previously only available in the older Office 365 Security & Compliance Center are now consolidated. Is there more to do? For sure. This is a great start though, and greatly simplifies day to day administration.

You can now sort, search, and filter your Conditional Access policies! Small as this sounds, this greatly eases CA administration in complex environments. This is public preview, so comes with some caveats… you can read more about the new experience here.

There’s a new Teams Pro service plan. The interest here (for me, anyway) is in the future vs. what this means now. This doesn’t introduce anything new. Teams Pro becomes the default service incorporated into M365 and O365 SKUs effective from March. I do anticipate some future changes though, specifically the (final) retirement of the Skype for Business service plan and (I suspect) some clarity around consumer vs. enterprise editions of the Teams service. Time will tell…

We’ve had another update to the ongoing legacy authentication story (other words may be more appropriate!). I’ve blogged about this previously see here, and should stress that organisations relying on legacy authentication should continue to focus their efforts on removing it from their environments. Urgently. That said, we’ve seen a relaxing to the timeline previously being followed by Microsoft during February. In their latest blog post the Exchange Team softened the approach being taken this year. If you are using legacy protocols, they will continue to be available. If you are not, you should anticipate their removal in line with the previous plan.

Azure

Soft Delete for Azure file shares is now enabled by default (for new Storage Accounts). I read someone’s experience of using this in practice on Twitter this week… a life-saver for you if you happen to have been unlucky (or careless?!) enough to delete something you shouldn’t have. Read more here.

The Azure Achitecture centre is a fantastic resource for those involved in the design and deployment of services on Azure. You can find reference architectures, sample diagrams, confirm recommended practices, and a whole lot more. This month it’s had a re-skin and re-launch, go and check it out!

Cost Management is now available for Government PAYG subscriptions. Cost Management is one of my favourite features, and now available across all major subscription types (regular PAYG, EA, CSP, Sponsorship, and now Government tenant PAYG). You can cut and shut your spend across resource groups, subscriptions, resource types, and tags, set spend thresholds and alerts, benefit from Azure Advisor recommendations, and a whole lot more. If you haven’t spent at least a bit of time in the Cost Management section of the Azure portal you really should… check it out.

Yet another Azure region is in the works. Enter East US 3. OK… so this may be of limited interest to my British and EU followers, but every expansion of the Azure platform is exciting, right?! More choice for multi-nationals looking for a local point of presence, another option for DR replication, and further evidence that Microsoft are here for the long haul. Standing up a new region is no mean feat. Multiple datacentres. Multiple services. A host of positions to fill to make it operationally viable. The pace Microsoft continue to move at in this space never ceases to amaze me…

More accreditations. This time in the form of extended HITRUST CSF, and a first PCI 3-D Secure (PCI 3DS) certification. A full rundown of the (copious) certification standards the Azure platform aligns to can be found on the Service Trust portal… needless to say though, the list is both ridiculous and highly impressive from the perspective of someone who looks after Security and Compliance. Concerned about data or platform security? It won’t be the platform that lets you down…

Certifications

I was pleased to see a number of new Security & Compliance certifications finally launch this month: SC-200, SC-300, and SC-400. I had the huge privilege of being involved in the creation of the blueprint for two of these exams and it’s great to see them go live.

All three are in beta for the foreseeable future, so those tempted to take one (or all!) will need to wait for their results… I’ll include myself in that list, and will post some first thoughts in the coming weeks as I do.

So there we are… just a few of the many noteworthy things that have happened so far in February. If you want to discover more I’d highly recommend you keep an eye on the Azure Updates page and the Microsoft 365 Message Centre. That aside, give me a follow on Twitter where I try to highlight anything new and noteworthy as I discover it.

Happy learning, and happy reading… What’s your favourite February announcement?

You could be forgiven for thinking that this site had been kicked into the weeds… lost in the myriad of other well-intentioned, but ultimately abandoned blogs that litter the internet. That was never the plan. I was asked specifically “what happened to the blog” recently and struggled for an answer. Having reflected, I thought perhaps I should pull my finger out and post something. It seems some of you like what you read on here (indeed, I’ve seen a good amount of continued traffic in spite of no posts of late). Perhaps surprisingly - given the lack of content - I also enjoy putting the posts together that end up on here 🙂

There’s something quite therapeutic about putting metaphorical pen to paper. Whether what gets written ends up getting posted is another question altogether… Irrespective, the process of learning, documenting, and sharing my thoughts is an enjoyable one. I don’t write to get feedback, but I do enjoy the interactions that come from putting content out there. I also appreciate the messages that come from people who have learned something new, or gained some sort of insight from my ramblings and taken the time to let me know. I’ve missed all of those things in the last 4-5 months.

So what happened?

So back to the point, what happened to the blog? Did I consciously stop writing? Was there nothing of interest to post after Continuous Access Evaluation? Did something happen? The short answer is none of those things. Life just got in the way, as I’m sure it has for most people of late.

It’s been a strange but busy few months. Lockdown 2 in the UK… closely followed by 3. Schools closed once again. An immensely busy (but successful) period at work, coupled with a role change that’s added some healthy (but enjoyable) pressure. I’ve simultaneously had both the most, and least time at my disposal than at any other point in my life. The truth of it is that the blog has taken a back seat at a time where I wish it hadn’t. There have been some failed attempts at posting, some half written blogs. Plenty of inspiration, but (perhaps) not enough motivation, that’s on me.

Is the blog done?

So is the blog done? In short, no 🙂 There’s certainly no lack of noteworthy tech to post about… Cloud adoption has sky-rocketed in the last year or so (for obvious reasons), as has the pace of innovation and rate which we’re seeing some awesome new things come to market from Microsoft. I’ve never been more excited to be associated with a vendor and set of technologies at a point in my career.

I can’t promise posts on a schedule, nor can I guarantee an influx of content in the coming days / weeks on the back of this one. I do though have every intention of getting back on the wagon… and I hope those of you that follow will continue to check in and feedback.

Watch this space…

I’d not spotted this in my own tenant, but an eagle eyed user (Thomas Naunheim) flagged it on Twitter yesterday… much to my (nerdy!) excitement. Continuous Access Evaluation (CAE) is now in Public Preview! Those of you who follow my ramblings will know I’m a sucker for identity related feature enhancements. Whilst this ticks that box, it also represents a whole lot more… ushering in a significant change to the way that risky and non-compliant sessions are managed by Azure AD. I thought it would be worth taking some time to explore the feature; outlining what it is and what it might mean for you…

Continuous Access Evaluation (CAE) was first mentioned a few months ago in the Azure AD Tech Community blog. Building on open standards OIDC and OAuth 2.0, CAE makes it possible for user sessions to be evaluated in real time. This enables more effective and robust policing of user access, and alignment of Zero Trust principles.

What’s changing?

Let’s consider how access is governed under during a “normal” session today. When a user accesses an online service (e.g. Exchange Online), requests are authorised via tokens issued by the authentication provider (Azure AD). These are provided at the point a successful authentication takes place, with a default validity of one hour. During this time all requests from the presenting party are authorised. Whilst we can manipulate this using Conditional Access session controls (see image) or by modifying token lifetimes, in either scenario we’re reliant on a period of time passing before a request is refused. This isn’t always ideal.

Why does this matter? Consider the scenario where an administrator needs to block access to a service immediately by disabling an account. Under the “normal” model the right to access is maintained until such time as the token refresh interval is reached. Only at this point is the user access denied which may not be desirable (consider a bad leaver). In another example, a user might legitimately satisfy a Conditional Access policy based on location (such as the corporate office) and then reappear in an unauthorised location within the session lifetime. In these examples we would prefer the session to be invalidated via the account being disabled, or through re-evaluation of the request by Conditional Access.

Continuous Access Evaluation Protocol (CAEP) changes all of this, providing a way for the resource provider (relaying party) to be notified by the identity provider where tokens should no longer be honoured. The trigger for this could be any number of things… a state change, a security event, an administrative action. Relaying parties will also be able to synchronise key policy elements to enable proactive session termination (i.e. not based on the IDP issuing a signal). Irrespective, and regardless of the token validity, the user can be prompted by the resource provider to re-authenticate – potentially denying access. Very cool!

Enabling Continuous Access Evaluation

CAE can be enabled within the Security section of the Azure AD Portal direct link, however you should be aware of some limitations in the short term. Obviously “preview” carries some caveats… limited support, likely to undergo some changes etc. etc. I don’t need to tell you that 🙂 Unique to CAE though are some specifics around where / how it applies.

First and foremost, CAE assumes “compatible” relaying parties and clients. Those which can interpret event information from the Identity Provider, and handle the requirement to permit access or invoke re-authentication based on that information. At present, this is limited to Exchange Online, SharePoint, and Microsoft Teams (with more planned for future).

In a similar vein, only certain conditions are supported at the moment. These are listed as:

• User Account is deleted or disabled
• Password for a user is changed or reset
• MFA is enabled for the user
• Admin explicitly revokes all Refresh Tokens for a user
• Elevated user risk detected by Azure AD Identity Protection

…again, more planned for the future.

Where CAE applies, Microsoft make an important note regarding “old” access token lifetimes:

Because risk and policy are evaluated in real time, clients that negotiate continuous access evaluation aware sessions will rely on CAE instead of existing static access token lifetime policies, which means that configurable token lifetime policy will not be honored anymore for CAE-capable clients that negotiate CAE-aware sessions. Token lifetime is increased to be long lived, up to 28 hours, in CAE sessions. Revocation is driven by critical events and policy evaluation, not just an arbitrary time period. This change increases the stability of applications without affecting security posture.

Continuous access evaluation: Microsoft Docs

Where CAE cannot be applied, regular access token lifetimes will be obeyed.

Summary

When I began writing up this article the “Learn More” link for CAE in the Azure AD portal wasn’t working. This has now been rectified and you can discover more about the inner workings here.

Tying in with some of my previous posts on Security in general (and specifically Zero Trust), I see the implementation of CAE as a huge positive. The underlying mechanism(s) by which authentication requests are processed have long been a blocker for true “Zero Trust” application and whilst minimal, the associated risks can’t be entirely mitigated.

CAE is a big step forward. Providing intelligence between the session, the endpoint, the connected application, and the administrator in way which far more logically aligns with a Zero Trust mentality. It marks the beginning of a new era for Azure AD aligned applications in my mind. It’s significant.

Stay tuned for more feedback on how it operates in practice, how it scales to other applications, and when it dips out of preview. In the meantime I’d encourage you to have a read of the supporting documentation and a play in your own environments. If you have questions I can help with, don’t hesitate to get in touch with me on Twitter.

A brief, but long overdue post to reference a long awaited - but now here - feature in Azure AD! The My Sign-Ins made a Preview appearance some time ago now. Relatively feature-rich from the off, it does what it says on the tin… aggregates and shows all sign-ins for the logged in user in a clear, simple to understand dashboard. As of a few days ago, it’s (finally!) entered the world of General Availability.

What is “My Sign-Ins”?

There are a host of ways to monitor Sign-In activity from an administrative perspective - Azure AD, MCAS, and Sentinel to name a few. Until now though there’s not been an easy way for end users to review their sign-in activity. More to the point, there’s not been a way for users to easily identify and report suspicious sign-in attempts. “Is that important?” I hear you cry… well yes! Who understands their activity better, and who can take proactive action more effectively than the end user?

By reviewing sign-in history users can quickly identify attempts to exploit their account. Take the below attempts to access my account today as an example:

My Sign-Ins will show successful authentications which the user might interpret as suspicious. This includes the location, service, and source IP. Obviously this would never happen because you all employ Zero Trust, use MFA, and your users would deny the random sign-in request. It’s useful none the less though 😉 Should such a situation occur, users can take action directly from the My Sign-Ins portal to secure their account.

New at the point of GA is the decision to present suspicious sign-in attempts detected by Identity Protection at the top of the list. Users can specify whether the attempts were, or weren’t them. This refines the behaviour of the Identity Protection service in the case of a legitimate sign-in, and triggers account protection measures if not.

Summary

Publicising the ability for users to monitor, validate, and search their Azure AD authentications might not be top of your list, but it does add huge value in empowering users to take responsibility for the use of their accounts. Go give it a whirl!

You can read more about the announcement here in the blog post from Alex Simons.

As the world has endured lockdown, the past few months (if not the year to date!) have been “odd” for many. I’m sure those of you reading might choose to replace that final adjective with other alternatives… Irrespective of your choice of words, 2020 for virtually everyone on the planet has been a defining year.

For the most part the focus has been on the negative. The day-to-day impact of lockdown. The countless personal tragedies. The impact on our health services. The long-term effects on the economy… I could go on. This past couple of weeks though I’ve found myself contemplating the things closer to home. The small victories. The many examples of initiative and hard work that have allowed things to continue with a sense of normality. The shift in the way people think and approach communication. There are many.

In spite of the horrific nature of COVID-19, things are happening around us that will continue to define the way we work and interact for years to come. There are also areas I’m sure many of us would admit we need to do better on in the future… a wake up call perhaps. Much of this is technology aligned and I’ve found it fascinating to see how the world has embraced a number of the services I love to talk about and work with, day in and day out.

I thought I’d take a moment to summarise some of the things I’ve noticed over these last 6-8 weeks (or is it 9-10… or 11-12… who knows anymore?!). Perhaps they resonate with you, perhaps they don’t. Either way I’m keen to hear your feedback. What are the positives you are looking to maintain following COVID? What things have you have noticed? What’s changed and is unlikely to revert post-lockdown?

Here goes…

Organisations & People Adapt

This is the biggie for me. As the lockdown became an inevitability many organisations were forced to consider the way they delivered services to their users with an initial sense of trepidation. Whilst technology sits at the heart of most modern businesses, for a significant portion this is (or at least was) in a very traditional way.

“Digital Transformation” is one of those phrases I have an instinctive negative reaction to (hear me out…!). It conjures up a vision of wholesale change, large expense, and for some represents an idealistic vision that seems unattainable. In practice this is rarely the case, but it’s become one of those phrases that often provokes a defensive response.

COVID-19 has changed that; forcing some lateral thinking and driving change based on the need to do something. In many cases it’s the fear of change as opposed to the cost or ability to effect it that prompts hesitation. Whilst I don’t want to typecast digital transformation (solely) as “remote working”, the modernisation of the user experience and flexibility that comes from adoption of cloud services is a huge part. The coronavirus pandemic and lockdown has acted as a significant catalyst.

In much the same way as organisations, people have also had to adapt. The illusion of a perfect working environment has been shattered; invaded by children, pets, and our often less than perfect desk setups. I’ve spent the last 7 weeks working from my kitchen table. It’s OK. Comfortable enough, and (now) equipped with a Surface Dock and decent monitor. It’s a far cry though from my setup at work, or the office I used to have upstairs… the one we decided just a few short months ago would be better served as a bedroom because “I hardly ever work from home anymore”(!).

The reality is that none of that has really mattered. Every other person I speak to has the same challenges, the same distractions. We’re all in the same boat. With that comes an acceptance that may not have been there had we not been challenged in quite the way we all have. A wholehearted positive in my opinion.

Video isn’t all that bad…

If you’re anything like me, in spite of having the tools at your fingertips the prospect of a video call used to be a daunting one. Of the many calls I participated in during a typical week only a small portion used to involve video. It wasn’t so much a novelty, just a feature that wasn’t relevant to most calling scenarios.

The importance of face to face communication has always been well understood. In a pre-lockdown world there was a fairly typical format to most customer engagements… preliminary interaction was nearly always by phone. Some fact finding. Some introductions. Any serious requirement though was nearly alway followed with an on-site meeting to discuss the detail. This felt like a necessity, enabling the free-flowing back and forth conversation that’s difficult to achieve on a call. As we’ve quickly come to rely on Teams, Zoom, and a plethora of others for our day to day communication, there’s been a marked relaxation towards the use of video to bridge this gap.

For me, video has become a default. Whether it’s a quick call to a colleague, or a more involved customer meeting my assumption now is that most attendees will have cameras enabled. Whilst I long for the day when I can go and visit customers in person once again, it’s hard to imagine us going back to a position where video doesn’t play a major part in the way we undertake business communications. It’s not the same (clearly!), but visual cues, the ability to easily interact with remote participants, and a broad level of acceptance / comfort will undoubtedly mean it’s used far more readily post-lockdown. That leaves aside the many other business benefits. Less time spent travelling. A reduction in expenses. The ease and speed with which we can interact and progress etc. It’s a no-brainer.

Video is very firmly here to stay.

Office Communication is Underrated

Notwithstanding the benefits of video and remote working, something I really miss is the hustle and bustle of an office environment and the working day… Countless small interactions played a large part in the way I managed my teams and the way I kept my finger on the pulse of what needed to be done. It’s amazing how much effort it takes to replicate that effectively when working remotely.

The danger of missing out on the incidental stuff is that you become a slave to meetings. Things that “just happen” in an office environment need to be instigated when you’re all apart. In practice this takes the form of calls. Lots of them. This is something I have had to (and am still learning to) manage more efficiently. Calls are rarely brief in spite of best intentions. It’s perfectly natural to want to catch up, to chat, and to try and make up for all of the “normal” things that we get up to when we’re in the office. The reality is that it’s nigh on impossible to replicate the passing comments in the kitchen, or overhearing a discussion and chipping in with some help…

I’ve struggled with this, and in truth I still do. I’ve found myself having to be far more selective about what I do and don’t get involved in - knowing full well that accepting every 30-60 minute call is self-defeating. I try to dedicate time each day to catching up with those in my team that isn’t focussed on anything other than making sure they are OK and have what they need. It’s not a perfect substitute, but it goes some way to making up for what we miss when we’re passing in the corridor or making a coffee. It ensures that more formal conversations we need to have during the day can be focussed and productive. That said, I’d trade it in a heartbeat to go back to the way things were.

BC / DR Plans aren’t Reviewed Frequently Enough

For many, the moment we entered lockdown was akin to a disaster. We often theorise on the scenarios that will trigger a BC / DR response. The usual “plane hitting the building”, or fire / flood type scenarios. The prospect of a mass event leaving offices perfectly functional but devoid of people however wasn’t high on many lists.

This was reflected in the way that some organisations found themselves having to respond. A mix of panic, chaos, hard work and in (most) cases… good fortune. I’ve made reference already to the way organisations and employee’s adapted. There’s an underlying point though that many weren’t prepared for what came along.

Obviously forecasting any and all DR-type scenarios isn’t possible. For me though there’s a broader principle here that needs to be noted for the future, focussed on architectural principles. We live in an age where most roles can be fulfilled remotely. There are obvious exceptions; manufacturing, hospitality, retail (etc.). In nearly all cases though there are examples of roles which can be made location agnostic with the right systems and infrastructure.

DR is about more than having a plan to recover systems. Indeed, with many systems now moving to SaaS the conversation is more about providing and maintaining access. This goes beyond basic conversations around laptops and a VPN. It extends to the way we manage devices, the way we securely access systems and data (Zero Trust anyone?!, and the processes and methods we use to manage employee communication and engagement.

Much like security, DR principles need to be built-in, not bolted-on. This is a lesson I think many have taken away from recent weeks. A “wake up call” sounds crass, but irrespective of your choice of words I suspect the focus on managing and maintaining BC / DR plans will shift as we move forwards.

Summary

The Cloud has defined business response in many cases. I’ve seen examples of work programs being accelerated, and lightbulb moments as the value cloud services can bring is realised in these oh-so-strange times.

This is slightly left-field of my usual posts (not to mention slightly longer) I appreciate. I feel though that COVID-19, and the resulting lockdown represent a watershed moment for our industry. I’ve been selective with my words in places. There are too many examples of organisations (and individuals) looking to capitalise on the pandemic with FUD and pressure-tactics. That isn’t my intention with this post. For me, there are some key learnings for us all. I want to recognise and learn from them.

There will be other examples many of you will have noted. I’d welcome some examples and some debate on my own thoughts. What have you seen? How will you learn from this period?

Hot on the heels of the MyApps portal updates last week, a number of Conditional Access updates have made their way into Azure AD. Those of you who follow this blog will know I have an unhealthy fascination with all things #Identity, so I thought I’d take the time to dive into each and explain what they mean to you…

Three features were announced in a blog post yesterday by Alex Simons. Whilst each is minor in isolation, collectively they address a number of things which have been requested for some time… specifically around visibility and reporting. The announcements are as follows:

• Report-only mode is now generally available
• A new “Policy Details” blade is now in preview
• The Insights & Reporting workbook is now generally available

Conditional Access Report-Only Mode

I touched on report-only mode for Conditional Access in one of my Ignite blog posts last November. At the time it was just entering preview and was wholeheartedly welcomed (at least by me!)… There are lots of things that send shivers down the spines of AD administrators. Cloud or otherwise. Changes that result in people being wrongly locked out of accounts is right up there! Report-only mode mitigates this risk, providing visibility on the impact of potential changes before they are made live.

When enabled, report-only mode records the success or failure outcome that would have been associated with a logon attempt. I’ve used this on a number of provisional policies I’ve been testing with and it works well. An additional tab appears in the sign-in logs that records two key things:

• The controls that would be associated with the policy being applied
• The applicability and outcome of the policy on that authentication attempt

This is immeasurably helpful when implementing new policies; sparing blushes(!), and providing insight into the results of those slightly less “standard” policies we sometimes find ourselves deploying. This announcement see’s this feature exit preview, and become fully fledged. It’s also now the default setting for any newly created policies. I’d encourage you to use it… set aside your impatience and let it run it’s course for a day or two before enabling anything new.

All New Policy Details Blade

I’ll mention this second, as opposed to at the end in line with Alex’s release announcement. For me, this flows quite logically on from report-only mode - providing visibility and insight into the behaviour of Conditional Access policies in a way which we haven’t had access to before.

You’ve done the right thing. You’ve deployed a policy in report-only mode, tested it thoroughly, and now you’ve deployed it to live. A number of your users are having issues though, why? In the “old” world, your visibility of applied Conditional Access policies was limited to Success, Failure, or Not Applied… Why did the policy fail? Why did the user fall within scope? What’s going on?! It has always been difficult to tell.

Policy Details seeks to address this by providing additional insight into applied policies. Where a policy results in behaviour we wouldn’t expect, we can now discover why. Not just “Failure” to apply, but “Failure because”. Against each Conditional Access policy within the sign-in log we can now expand the view to show us which criteria were satisfied (or not).

Take the following simple example, I have a policy which blocks legacy authentication in my tenant (don’t we all?!). It’s not been applied to a recent sign-in attempt where perhaps I expected it to be. Using the Policy Details view I can determine that whilst the resulting action would have been a block had the conditions been met, in this case my browser (unsurprisingly) doesn’t match the Client app defined in the policy:

This is a super-nice bit of visibility to have when troubleshooting… It’s currently in preview, but should be visible in your tenants already. Give it a go!

Insights & Reporting Workbook

The final part of the announcement (albeit not in quite the right order!) relates to the general availability of Insights & Reporting for Conditional Access. “Insights” terminology is used throughout the Azure portal to monitor, identify trends, and generally get a view as to the health of various resources deployed. This has been lacking when it comes to Conditional Access, with only limited reporting available - unless you are familiar enough with KQL and Log Analytics to construct your own queries.

The new Insights & Reporting blade for Conditional Access addresses this direct link here. Leveraging diagnostic logs from Azure AD, it provides you with some visual analysis of your policies, and the authentication traffic flowing through them:

You can filter by policy to see where, to what, and to whom your policies are applying. You can also search against users or response types to gather additional detail on the effectiveness of the policies you have defined.

It’s worth noting that this view is an extension of the regular “Workbooks” that are available in Azure AD (once you’ve configured forwarding to Log Analytics). These are incredibly useful when it comes to analysing authentication traffic in your environment, or when looking for specific types of activity (such as legacy authentication requests). You can access these in the regular Azure AD blade here. Naturally you can also delve deeper within Log Analytics should you choose.

There are some preliminary steps you need to run through to gain access to these views if you haven’t already:

• Ensure you have an active Azure subscription
• Create a Log Analytics workspace (if one does not exist)
• Enable diagnostic log forwarding from Azure AD (audit logs, and sign-in logs)

These are detailed more fully in this Microsoft Docs article, but once enabled you’re good to go.

Summary

Unsurprisingly, these are welcome additions from my perspective. Some we were expecting… report-only mode has been a while coming… for others though (notably Policy details) these changes represent a positive improvement in administrative controls which aid visibility, and the ease with which changes can be implemented.

Azure AD remains one of the most underrated parts of the Microsoft Cloud stack for many of the organisations I speak to. Particularly premium variants. Security controls, like Conditional Access, and the ease with which they can be used to better secure not just Microsoft workloads, but a whole host of SaaS applications make it an absolute no-brainer for many organisations to embrace far more fully than they do. I’ll continue to bang the drum… and I hope Microsoft continue to innovate and add value to the product in the way that they have to date. It’s a brave new world!

If you haven’t already, please, please look at some of what you can do with Azure AD. If you have questions… please ask away!

I posted an update I’d noticed this week on the new MyApps experience coming to Azure AD. It made reference to the upcoming switchover, confirming that the old portal would be retired in late July:

In my mind it was a fairly minor bit of news. The new experience has been in preview for quite some time and isn’t the most exciting aspect of the end user experience… Based on the response though, it seems not everyone is aware of what’s to come. At the expense of an hour or so on a sunny, lockdown afternoon, I thought I’d take a moment to expand slightly on my initial 220 characters…

So what’s happening?

The MyApps portal is a too often forgotten part of the Azure AD user experience. Unlike the Microsoft 365 portal, the MyApps portal collates every application you have access to into a single view. This covers the integrated Microsoft 365 applications, and third-party SaaS applications. I’ve covered some of the advantages of doing this in a previous post, along with a simple guide on how to achieve it. It’s powerful when used to its full capacity. If you aren’t already doing it, you’re missing a trick.

The change is largely a cosmetic one, updating the interface from one that looks like this:

To one that better aligns with the look and feel of other modernised portals:

The refresh also makes way for some other new functionality that’s particularly useful if you’re leveraging Azure AD in anger; App Collections. App Collections extend the new MyApps experience, providing a way for you to organise applications for your end users for the first time. You can read more about this new bit of functionality here in Microsoft Docs

What do you need to do?

If you haven’t already, I’d encourage you to activate the preview on some test accounts to familiarise yourself with the new experience. It takes less than 5 minutes, and I can almost guarantee you’ll quickly roll it out across the board and have a new appreciation for what MyApps can bring to your organisation.

To do so:

• Create a new Security Group containing users you want to target
• Navigate to Azure AD > User Settings > Manage user feature preview settings
• Toggle the “Users can use preview features for My Apps” option to “Selected”, and target your test user group

After you’ve enabled the feature and targeted your users, you can turn-on the experience in the MyApps portal. Load MyApps as normal and click on your profile picture. In the menu that appears you should see the option to enable the new MyApps experience:

Click this, et voila! You can undo the changes at any time by reversing the steps above. Alternatively you may be comfortable enough to take the plunge and enable for all. Irrespective, your users will all see the new experience come July.

In Summary

This obviously isn’t a deep-dive, but the above (brief) detail aside, there’s little more to be aware of, save having a play with app collections once you’re up and running. This is a relatively minor update in the grand scheme of things, but one that seemed to pique the interest of those that follow me on Twitter in particular.

My hope is that Microsoft continue to develop MyApps. Collections bring a nice bit of administrative control to what users see over the old experience. The new portal is also much nicer to view and navigate. The lack of ability to sort, customise, and show / hide / prioritise applications at user level is still a frustration for me (and others) however…

The MyApps portal has the potential (and ambition, I think) to be the one-stop shop for your applications, data, and third-party services. These changes bring it a step closer, but there are additional improvements that can be made. Let’s hope they come… 🙂

FIDO2 is something I’ve referenced previously on here, albeit not in too much detail. Many only take a passing interest in what this standard is and its importance when it comes to popular concepts like passwordless authentication. This was confirmed to me today as I found myself browsing through the responses to a recent @SwiftOnSecurity post on Twitter:

The crux of the conversation that followed was the lack of support LastPass has when it comes to supporting FIDO2 standards. Why is this important though, and why should it be a factor in how you select services (like password managers)?

For the record, I’m a longstanding (premium) user of LastPass. It’s served me well over the years and still has some neat features not available in many alternatives. That said, the lack of progress when it comes to support for passwordless / WebAuthN has been a frustration for many (myself included). Thinking and principles around authentication security have matured significantly in recent years. Multi-Factor Authentication (MFA) has become mainstream, as have friction-less sign-in solutions like Windows Hello. FIDO2 is a major contributor to this; in terms of both user experience, and security standards. As people become more aware and less accepting of “poor” progression on these fronts, the importance of adopting new standards become all the more important.

The response from LastPass has been woefully inadequate, with many informed users taking services elsewhere as a result.

So what is FIDO2?

Before we talk FIDO2, we should first cover the basics of the FIDO Alliance and it’s contribution to date. FIDO is short for “Fast Identity Online”, an industry alliance focussed on improving authentication standards. It’s ultimate objective is minimising (or removing) passwords altogether. This is made possible through the adoption of common standards across the industry.

The original FIDO standard attempted to reduce the importance of passwords through an approach built on public key cryptography. This is known as the Universal Authentication Framework (UAF). Unlike traditional authentication approaches that require the transmission of a password, the FIDO standard relies on a local action. This can be the providing of a fingerprint, entering of a PIN, inserting a security key etc. and results in access a locally held private key. This key is used to sign an authentication request, which can be decrypted by the public key available to the service.

UAF has been enhanced with the Universal 2nd Factor (U2F) standard. This provides support for two-factor authentication (2FA) alongside UAF, and replaces traditional OTP solutions with USB, NFC, or Bluetooth equivalents. The net result is a streamlined experience for the end user, minimal prompts or interaction.

It’s with that background, that we can discuss FIDO2. This new(er) standard builds on FIDO 1.0. Leveraging U2F alongside a new web API called Web Authentication (WebAuthn), FIDO2 allows web applications to use public-key encryption and authenticators directly. This is integrated into browsers, allowing users to log in using biometrics, mobile apps or FIDO2 security keys. There’s no need for a username or a password… true seamless, friction-less, and passwordless authentication!

What does it mean for you?

Coming full circle, let’s apply this logic to services like LastPass. When compliant with FIDO2, no password is exchanged with the service at logon. The presence of a FIDO2 device, or access from a FIDO2 certified platform (such as a Windows Hello enabled laptop) allows access to the service. This is achieved in a manner which also satisfies MFA. In the context of a service entrusted with sensitive information this should be a given in 2020. Certainly far better than a master password that can be compromised, or a clunky integration of 2FA via an OTP code…

FIDO2 will change the way we consume and authenticate against online services. The backing of organisations like Microsoft, and integration of FIDO2 into platforms and applications means that this level of security is capable of being mainstream… if adopted by application vendors.

Translating this into a real world example, we can consider the way Microsoft have embedded FIDO2 and WebAuthn into Windows 10. As an end user I can walk up to any Azure AD joined device in my organisation and present my FIDO2 compliant YubiKey. Coupling this “something I have” with “something I know” (a PIN), I can be logged into the device without mention of a username or password. The same is true when accessing online services backed by Azure AD… Insert the key, enter the PIN and you’re in. No fuss, ultra secure.

The LastPass example may be of minor relevance to most of you reading. The principle is universal though. Open standards like FIDO2 provide the mechanism for simplicity, security, and minimise the risk of data breach. End users might not appreciate the detail, but I can guarantee you they’ll appreciate the ease. Your CISO will thank you too… 🙂

After much procrastination and delay, I finally got around to sitting (and passing!) my AZ-500 exam this last week. Having posted previously on my experiences with the MS equivalent (MS-500), I thought I’d repeat the process for AZ-500. To anyone preparing for, or considering taking AZ-500, I hope you find this brief overview useful…

For those unfamiliar, AZ-500 is the exam focussed on the security aspects of the Azure platform. This goes beyond the Microsoft 365 elements covered in MS-500, looking instead at the infrastructure and platform aligned tools that can help you to improve your security posture when leveraging Azure. A full summary of the skills measured can be found on the exam page. By way of an overview though, the following key areas are measured:

• Managing Identity & Access (20%-25%)
• Implementing Platform Protection (35%-40%)
• Managing Security Operations (15%-20%)
• Securing Data & Applications (30%-35%)

I’d been considering this exam for some time, it’s a logical follow-on from MS-500. For various reasons though I’d put it off, and put it off… until finally I figured I’d just get on and book it to give me a deadline to work to 🙂 The impetus to finally get on with it was two-fold. One, having exam passes in both AZ-500 and MS-500 is a pre-requisite to the new(ish) Microsoft Security competency. Two, I plan to spend some considerable time over the coming few months working on some security-centric activity. These things, coupled with some time over the Christmas period ended up being the catalyst I needed. With hindsight, I wonder what took me so long!

So how was it, and what are the key things you need to know to help you prepare for the AZ-500 Exam?

Some initial repetition here with my MS-500 post: If you’re here for the inside scoop / gossip in the form of exam content, you’ve come to the wrong place. That’s not my style, and I’d suggest you have a read of this link 😉

What follows are some pointers based on my experience, and some useful content that will help you on your way…

Know your content. Some more needless repetition, but every bit as valid. You absolutely need to have real world experience on the topics covered in this exam. Know your way around the Azure portal, have a sense of the various services that are available, and understand how they interact with one another. This exam in particular goes well beyond the “how does this work” style of some others. You need to be familiar with concepts and principles as much as the mechanics of how things are configured.

Be prepared for Labs. This exam isn’t all about Q&A, there’s a lab based element too (sorry, “Performance Testing” element 🙂). You will need to put into practice the things you are expected to know. I only had a single lab, but it was wide-ranging - covering Storage, Key Vault, IAM, Monitor, Azure Security Center, and a number of other elements.

Read the Microsoft Azure Cloud Adoption Framework (CAF), notably the strategy, plan, and govern sections. This document lays out the recommendations Microsoft want you to be aware of when it comes to Azure planning and adoption. You’ll also discover best practice references which will help you to narrow down your responses to some of the questions.

Don’t rely on your own understanding, read / learn more widely. Microsoft Docs is a resource which has come on leaps and bounds since the days of TechNet. Detailed how-to guides, in addition to deep-dives on specific features and services are available in abundance. Focus in on the areas you feel weak on, and take advantage of some of the guides others have put together which collate useful links for learning. I found the following particularly useful in my preparation:

• Preparation Guide for Microsoft AZ-500
• Microsoft Azure Security Engineer (AZ-500) on Pluralsight
• The AZ-500 Exam Preparation session from Ignite 2019

Have the right learning foundations in place. If you haven’t already, I’d suggest you take AZ-103 before you sit this exam. Much of the AZ-300 / AZ-301 content is also relevant, specifically design principles around governance which extend naturally into the security considerations AZ-500 focuses on.

Performance Testing Gripes…

It wasn’t all plain sailing for me, and whilst I typically refrain from negativity in these posts, this feels worthy of a mention. When it came to my lab section (I had just one, with ~12 tasks from memory), I encountered a couple of issues that totally threw me for 5-10 minutes. In the grand scheme of things it made no difference, but had I been tight for time or close to passing I’d have been more than a bit annoyed. I know I’m not alone on this - colleagues have experienced similar - but to anyone at Microsoft reading this, the labs have to be solid and reliable if they are to continue to increase in their importance within exams.

For the record, I think Performance Testing is a good thing. It minimises the use of cheat-sheets / dumps (which have become so prevalent). It also better assesses candidates understanding of the things they should know… That said, every experience I’ve had has been poor. Labs crashing, poorly worded tasks, or insufficient access to complete tasks.

I won’t give specifics away, but there were two activities I had to skip. One due to a lack of permissions within the environment. The other down to a badly worded question which didn’t match the lab environment I had access to. Neither was a disaster in my case, but annoying none the less to know I could have scored better than I did…

In Summary…

As is typically the case with these more focussed exams, much of the content is niche in nature. A significant portion of the content is probably only relevant to a subset of customers I deal with. Notwithstanding, it never ceases to amaze me just how vast and comprehensive the Azure portfolio is. Would I recommend you take it? If Infrastructure Security is your thing, or an area of interest - absolutely.

For those interested, I secured a fairly respectable score of 823. Not a scrape, but by no means an ace. I couldn’t possibly admit to forgetting about having booked it for the day I did… fortunately I didn’t need the excuse! I enjoyed this exam. It gave me an opportunity to cement my understanding of some specific services. It also opened my eyes to some new services I’d previously glossed over.

To those who have stumbled here looking to take AZ-500, good luck! I hope at least some of this has proven useful in your search for information! ?

A slightly random entry today, triggered largely by a post on the Microsoft Tech Community forums this week. The post in question was asking whether it was possible to authenticate to YouTube with Azure AD - specifically, whether it was possible to securely access a shared account without divulging credentials. For many organisations shared accounts are a necessity, particularly with reference to platforms like Twitter and YouTube. Teams of people often contribute content to these sites, with credentials routinely shared. This is problematic when it comes to leavers - triggering a need for passwords to be reset which then need to be memorised all over again. Azure AD provides a neat way around this which we’ll discuss below.

I’ve written in the past about the advantages associated with integrating SaaS applications with Azure AD. The solution here is an extension of that principle. I expected to be able to quickly track down a guide on how to implement this for the poster, but struggled to do so. I jotted down a quick response and decided I’d pop my own guide together instead. A couple of days later, here we are…

The specific feature I want to cover is the ability for credentials to be bound to a user for an application in Azure AD. The application portal is one of Azure AD’s most useful features (in my opinion). It provides a single point of access to all corporate applications - Microsoft or otherwise. In this case we can create a link to YouTube that’s published to users. When clicked the user will automatically be signed in. Unlike a “true” SSO app, this won’t authenticate using the users Azure AD credentials. Instead, we’ll allocate the username and password which will be populated automatically when the link is clicked. We’ll also benefit from additional audit tools - with the ability to track usage through app sign-in logs.

Integrating YouTube with Azure AD

The first step is to navigate to our Azure AD portal and select the Enterprise Applications section. We are going to add a new application for YouTube by selecting “New Application” and searching for YouTube in the gallery:

After clicking “add”, the YouTube app will be registered with Azure AD, after which we can modify several properties to make it available. Select YouTube from the list of Enterprise applications and you should be presented with the overview page:

There are a couple of changes to the default configuration. We need to make it accessible to users, and we need to provide our shared account credentials. First of all we’re going to configure the application so it will present credentials when clicked. By default, think of the app as a dumb link - it will direct users to YouTube, but they will need to manually login. As mentioned earlier we don’t want to authenticate using Azure AD. Instead, we want to select “Password-based” sign-in from the Single sign-on section of the app:

This sets the URL the application will call when clicked by the user - directing us to the Google sign-in page:

We then need to assign our users (or groups) to the app. Navigate to “Users and groups” within the application properties and add the relevant users:

The next step is the key one. We need to assign our shared account username and password to the user or group. We do this by selecting the user (or group) and clicking “Update Credentials”. In the dialogue that appears we can insert the username and password for our YouTube account:

Click save, and we’re ready to test…

Testing the Azure AD Application

Sign in to the Microsoft MyApps portal myapps.microsoft.com with a user account assigned to the application. You should see the new YouTube application listed amongst your assigned applications:

If you don’t already have it installed, you will need to install the MyApps Secure Sign-In Extension. Your browser will prompt you if this is the case:

Once installed, and after a brief pause when you select your Azure AD application, you should be directed to the Google sign-in page for YouTube. The credentials bound to the user in the previous “update credentials” step will be replayed automatically, and you will be signed in with your shared account.

Summary

This is a really neat use of Azure AD to both simplify and better secure access to shared YouTube accounts for organisations. The same logic can also be applied to other web based services (e.g. Twitter). In this example the username and password combination is never made directly available to the end user. We can assign / unassign the application as necessary, and ultimately be assured that if a user leaves the organisation or no longer needs access, the underlying credentials remain secure.

I hope you’ve found this post useful, feel free to ask away in the comments if you have any follow up questions.

This week saw the (preview) release of Azure AD Connect Cloud Provisioning. For those still catching up on Microsoft Ignite news those words might not mean much to you. Dig a little deeper though and you’ll realise that this is a big deal. From my perspective it was one of the biggest bits of news to come out of Ignite, and something I made reference to in the highlights video that Transparity" posted while we were out in Orlando.

A challenge faced by an number of organisations, is what to do following a merger or acquisition. We live in an age where this activity is common, and poses a real challenge to many IT departments. Businesses expect the rapid coming together of infrastructure(s) to provide a simple and seamless experience for end users. This often begins with communication and collaboration capabilities; email, file sharing, and messaging services like Microsoft Teams.

There are two perspectives to achieving this with Microsoft Cloud. On the one hand it can be seen as a simple enabler for the coming together of these common services. On-premises data and applications that take considerable time and effort to consolidate can remain as is, whilst front end services can be stitched together via the cloud. A facade in some respects, but one which can be ultra-effective in M&A scenarios where perception is key. On the other hand, this process can be as fraught with complexity as the back-end systems being deferred. Central to its success is the ability to consolidate user objects into a common Azure AD. Simple if you can meet the prerequisites. Painfully difficult if you don’t.

What are the Challenges?

Any mid-large scale organisation will be familiar with Azure AD Connect (AADC). In ultra-simple terms, AADC provides for the synchronisation of user objects and passwords from an on-premises Active Directory, to Azure AD. Without it you are forced to manually manage multiple identities for end users - one on-premises for local resources, and one in the Cloud for Microsoft 365 and other connected services. AADC bridges these two environments - providing for password synchronisation, automatic user provisioning, and similarly de-provisioning / blocking of users when they leave.

AADC supports a multi-forest model - meaning you can synchronise objects from multiple local Active Directory environments. There’s one key caveat though. The Active Directory environments must all be capable of being referenced by a single AADC instance. The deployment of multiple AADC instances synchronising objects into a single Azure AD is not supported:

For some organisations, this is relatively simple to fix. You can connect all sites to an Azure environment and deploy DC’s for all, alongside a central AADC instance. Alternatively you can connect the remote forest(s) to the on-premises environment hosting an existing installation of AADC via VPN / MPLS. There are various things that can complicate this though - networking constraints or company politics to name just a couple…

How does Azure AD Connect Cloud Provisioning help?

Azure AD Connect Cloud Provisioning is an entirely new approach to user synchronisation. It does away with the 1:1 limitation of AADC and Azure AD. It also removes the need to host an AADC instance at all for those organisations looking to simplify their approach to hybrid identity. It’s entirely new, and entirely welcome for those complex, or politicised organisational coming-togethers.

Through the deployment of on-premises agents, we can now connect multiple, distributed Active Directory environments to a single Azure AD. The provisioning configuration is stored in the cloud and managed as part of the service. There’s no more local processing.

We can also deploy multiple agents - providing for high-availability in much the same way as we can with the Pass-Through Authentication (PTA) agent.

Are there any limitations?

The short answer is yes. Several as it happens, although I’m hopeful at least some of these will be addressed during the course of the preview. Key limitations from my perspective are as follows:

• No support for Device Objects (users, groups, and contacts only)
• No support for pass-through authentication (whether you should be using this or not is worthy of another blog post…)
• Filtering is possible only via Domain, OU, or AD Group, not by attribute
• Writeback isn’t supported (perhaps the biggest constraint in my opinion…)

A full summary of the available features, along with a comparison matrix vs. Azure AD Connect can be found here.

How can I get started with Cloud Provisioning?

If you haven’t seen it already, you can read the Tech Community blog post from [Alex Simons](https://twitter.com/Alex_A_Simonswhere he discusses cloud provisioning in more detail. The service itself is accessed through the Azure AD Connect section of the Azure AD portal:

From a configuration perspective there are two key steps:

• Deploy the Provisioning Agent
• Configure a Cloud Provisioning profile, specifying domain, filter, and password hash synchronisation options

A deployment guide covering both of the above steps is available on Microsoft Docs: Installing AD Connect Cloud Provisioning.

In Summary…

Azure AD Connect Cloud Provisioning is an entirely new approach to the synchronisation of users and passwords into Azure AD. It enables new use cases, deals with some significant constraints in AADC, and provides some insight into Microsoft’s strategy for user provisioning moving forwards. It’s a big deal.

Is it perfect? No, but it’s early days. It’s also only in preview… Current caveats aside (of which there are many), it’s well worth considering for those organisations who find themselves at the sharp end of M&A activity.

Take a deeper look, consider giving it a go, and let me know what you think!

I’ve been meaning to write something along these lines for some time now. The concept of the changing IT perimeter is something that’s front and centre for many organisations as we approach the end of 2019. For most it’s no longer the case that data, applications, and users are secured at the network perimeter. We talk less about keeping the bad guys out, and more on the application of security at the data and identity level. This is a world away from security of old. It also requires a shift in mindset for those tasked with implementing security. For these reasons and many more we’ve seen the birth of Zero Trust as a concept. What does this actually mean though, and what are the principles associated with its implementation?

A conversation with a customer this week focussed my attention and prompted me to write down my own thoughts on it. Some argue that Zero Trust is another one of those buzz-phrases - something that will diminish as time goes by. I tend to disagree. Is it a buzz-phrase? Perhaps. Irrespective though, the principles that underpin it are significant. It’s also an essential component in the era of cloud.

Why Zero Trust?

I discussed some of the drivers for modern management in a recent presentation I delivered. Many of these principles feed into the need for a different approach towards security too, specifically:

• Mobility. Users increasingly have an expectation of working remotely, and at different times of the day and night.
• Modern Devices. In the same vein, users now expect to be able to access and work on corporate content across an increasingly wide array of mobile, laptop, and desktop devices.
• Expectations. Corporate IT shouldn’t be a step behind. Newer ways of working, the ability to share and collaborate on data, and the availability of services from anywhere / at any time are available at home. Users expect this in the workplace too.

Accommodating these new approaches to working requires a different approach to security. One which does away with the assumption that we consume IT in a way which is secure by default. Devices, applications, and data which sit outside of the traditional perimeter are the new norm. This is where Zero Trust comes in to play.

So what is Zero Trust?

The statistics above were displayed at a session I attended at Microsoft Ignite: Zero Hype – Taking practical steps towards Zero Trust. They do a great job of further framing some of the comments I make above. The session went on to discuss Zero Trust in more detail. There was a specific focus on dispelling some of the myths and FUD associated with Zero Trust across our industry; this is a big issue in my opinion. I’d really encourage you to watch the session if you get the chance.

At it’s core, Zero Trust is an approach that encourages verification at as many layers as possible when accessing resources. It promotes strong identity, device health attestation, and the principle of least privilege. It also encourages consideration of the assumption that every access attempt is a potential risk. This approach challenges traditional approaches to identity and security. It also brings these approaches up to date with modern ways of delivering data and applications to users - notably those that are cloud based. Ultimately the concept of Zero Trust promotes a good security posture by taking an “assume the worst” stance.

What Zero Trust is not is something you will ever “be”, or something you can pay a vendor to provide for you. It’s not a literal thing, or something you can achieve overnight. By taking into account basic ZT principles though, you can dramatically reduce your chance of being caught out by the changing behaviours of the modern workforce. Those in heavily governed sectors are likely to find that embracing a Zero Trust mentality will aid the adoption of cloud. From my personal experience, it will certainly appease some of the Security team 🙂

Your Journey

So how do you get there? What, at a practical level, can you do to kick off your Zero Trust strategy? There are some key areas to target, the first of which is that mindset change I mentioned above… Change your way of thinking when it comes to security to one that assumes everything is a risk. Think of everything as a cloud service, and aim to implement the practices you might be already be associating with select applications, across the board.

I made reference to a bunch of things you should be doing with Azure AD in a previous post. Start with these and strengthen your approach to identity. Integrate applications so you you can secure them consistently, and implement PIM to ensure least privilege. Identity is a great place to start, and a fundamental when it comes to secure cloud adoption.

Focus also on device attestation and compliance. Use solutions like Microsoft Endpoint Manager (Intune) to manage devices, and impose compliance baselines. Feed these back into your identity platform to make informed decisions around when, and to what level you allow access to your resources.

Understand your applications. Invest in a CASB solution like Microsoft Cloud App Security (MCAS) so you can identify, and manage the services your end users elect to use. Again, integrate these with your identity and device management solutions so you can invoke real-time controls based on user behaviour and activities.

Assume that your data will end up outside of your perimeter. Take advantage of data classification solutions like Microsoft Information Protection to enable document level encryption and controls that extend your control beyond the traditional edge.

In Conclusion

These are just a handful of the things that you can do to get started on your Zero Trust journey. The key message from my perspective is that it’s exactly that - a journey. There’s no hard and fast rule-book. There’s no one solution you can go out there and buy which will help you to “be” Zero Trust. There are however, a number of really simple to deploy features that many organisations will have access to already. Layer these together, have the right mentality, and the end result is that Zero Trust - buzzword or not - is something that will greatly aid your overall security posture.

I hope this post has been useful at dispelling some myths around Zero Trust. What it is, what it’s not, and crucially how you can begin to embrace it yourselves. By way of additional reading I’d urge you to take a look at the following other resources:

• This session from Microsoft Ignite: Zero Hype – Taking practical steps towards Zero Trust. The source of a couple of the graphics in this post, and delivered by the excellent Alex Weinert.
• This additional Ignite session: Implementing a zero trust security model at Microsoft which discusses the transition Microsoft have made towards Zero Trust within their organisation.
• Microsoft’s Zero Trust Portal: aka.ms/Zero-Trust

As always, comments and feedback welcome!

For those not aware I had the incredible opportunity of attending Microsoft Ignite in Orlando last week. Those that follow me on Twitter or LinkedIn may have tired of my incessant updates, but for anyone who’s attended previously you’ll be aware of just how much is crammed into a few short days. I felt obliged to make at least some noise on social media given the volume of product announcements and news that surfaced. Part of that “noise” came in the form of an Ignite highlights video, put together by the team at Transparity in the closing days 🙂

Those of you who know me personally will know how thrilled I would have been at the prospect of being on camera… I’m far better suited to being behind the camera, or involved in the edit! That said, it came together surprisingly well, in spite of some “umming” and “erring” along the way! If nothing else, it served as a good practice for the next time!

We chose to cover some of the key announcements from the week, specifically:

• New features for Microsoft Teams
• Upcoming updates to Windows Autopilot
• Azure Arc
• Project Cortex
• Microsoft Power Virtual Agents
• Power Automate
• The coming together of Configuration Manager and Intune
• Migration enhancements coming to Azure AD and Exchange Online

See what we had to say below:

I made reference to a number of sessions I was looking forward to in my Microsoft Ignite: Coming Uppost. By all accounts all of the things I was looking forward to lived up to (and exceeded) my expectations. I met some fantastic people, put some faces to names, and learned a HUGE amount over the course of the week. It was truly one of the best technical events I’ve attended… bring on next year!

Unsurprisingly the last few days at Ignite have been a whirlwind of news and learning. From my perspective the conference has been everything I’d hoped it would be… and then some! Those of you following me on Twitter and LinkedIn will have seen an increase in spam(!) from me as I’ve tried to communicate some of the key exciting things being discussed. Whilst I’ll be doing my best to summarise those on here over the coming days and weeks, I wanted to take a moment to call out a couple of specific Conditional Access updates I felt were worthy of note.

If you follow this blog you’ll know that Identity, and Azure AD are two of my favourite topics. I’ve written about Conditional Access in particular on a number of occasions. One such post related to the built-in baseline policies that Microsoft introduced earlier this year.

In response to these additions. there’s been much debate around where and how they should be used. Microsoft have provided some clarity in recent months, implying that their use is (really) limited to smaller organisations without the skill or licensing to support manual setup. As a general rule, manual policy configuration will provide the most flexibility, but it isn’t always feasible or ideal. In response to this there are some changes planned to the way that baseline policies are applied to tenants. The world as you know it is about to change…!

Security Defaults

Microsoft want to encourage good, simple security for smaller organisations and effective use of Conditional Access for larger ones. To address this we’ve seen the introduction of Security Defaults. This is a setting which can be enabled at the tenant level to enforce good practice.

It’s also one which will replace the existing baseline Conditional Access policies in the early part of 2020!

Moving forwards this single option will enable recommended settings that were previously incorporated into some of the baseline policies. You can find this setting in the Azure AD portal under Properties, “Manage Security Defaults”:

Toggling this setting to “on” automatically enables a number of things:

• All users will need to register for Multi-Factor Authentication
• Privileged Accounts will need to perform MFA at each sign-in
• End Users will need to perform MFA once registered
• Privileged Operations will require MFA
• Legacy Authentication will be blocked

Further detail on each of these settings can be found here.

An important thing to note is that Security Defaults cannot be used in tandem with Conditional Access. Microsoft’s assumption is that you will use one or the other. Conditional Access where skills and licensing permit, and Security Defaults in other scenarios. Attempting to enable both will yield an error:

Report-Only Mode

A second (and quite excellent!) change is Report-Only mode for Conditional Access. This is something that’s been hinted at for some time, and is ironically something I stumbled across the day before Ignite in my own tenant. It’s an incredibly useful addition.

The long story short is that when enabled, Conditional Access policies will fire as if enabled, but resulting actions won’t be enforced. They will be logged though, so the potential impact of a new policy can be evaluated.

You can read more about Conditional Access Report-Only mode here on Microsoft Docs.

At face value, both of these Conditional Access updates are minor. They certainly didn’t capture headlines at Ignite in the way some other announcements did. In both cases though they’re significant, reducing administrative effort and aiding the implementation of good security practices that are perceived as either too complex, or too risky.

If you haven’t already, I’d encourage you to take a deeper look at both. As a trusted supermarket retailer here in the UK would say… every little helps!

I write this at the end of the first “proper” day of Microsoft Ignite 2019. Quite an amazing day for a whole bunch of reasons, but not least the announcement of several big news items. Front and centre for me was the converging of Microsoft Intune, and System Centre Configuration Manager (SCCM) into Microsoft Endpoint Manager. Two big names in the device management space. What does this actually mean though? Is SCCM dead? Is Intune no more? Does this spell the end of co-management? The short answer is no, to all three of those questions. Notwithstanding, this is a big deal, and one that needs a little more explanation than the headline gives away.

I was fortunate enough to hear Brad Anderson discussing the rationale behind this change live, in his Modern Management session this afternoon (BRK008). The stream is already available, the associated slides will be shortly. I’d suggest you take a listen if you haven’t already. I’d also suggest you read his accompanying blog post which also went live today.

Why?

The thinking behind the change is entirely logical. The basis lies in the fact that for a long time now, Intune and SCCM have been perceived as competing (or at the very least, disjointed) products. In a lot of respects, this is true. Intune has long been seen as the modern / cloud counterpart of SCCM (with some feature gaps). SCCM has been seen as the lumbering on-premises solution with a limited shelf life. Neither of these statements is necessarily true. Each of the products has positive and negative attributes, and together they are a formidable force. Today’s announcement cements that.

Not helping the matter has been co-management. As Brad indicates in his post, this has often been seen as a tool. A bridge. The means to get from A (on-premises) to B (Cloud). The destination analogy is far more accurate - not in the sense of getting to Cloud, but in the sense of getting to a far better management position. Co-Management is something you should use if you are able to - not just to migrate, but to add value to your device management operations.

The Future of Endpoint Management

So what’s actually happened? Is it just a re-brand? The answer, again, is no. In tandem with the branding references, there were also some significant feature announcements included today. Visibility of MDM, MAM, SCCM, and co-managed devices in the Microsoft Endpoint Manager (formerly Intune) portal has been improved - it’s now a true single pane of glass. Interoperability is also enhanced. A number of SCCM activities can now be executed directly from the Endpoint Manager portal (e.g. Application distribution). On the face of it these are small things, but again - watch the session recording. These are a big deal, and will lead to significant time-savings and efficiencies for IT teams once the power of this partnership is realised. They are also just the beginning.

Coupled with the operational changes, were some licensing simplifications.

Historically licensed users of Intune have been able to deploy SCCM through “equivalent use rights”. This entitlement has often been used as a temporary step - covering existing SCCM instances and aiding the transition to Intune. This now also works in reverse, with SCCM licensing now providing full access to Intune (for Windows devices). Either way around, you now have the full power of both SCCM, and Intune at your disposal.

Summary

This was a really interesting, unexpected announcement and changed some of the opinions I held on the future of SCCM. It’s clear to see that Microsoft see huge value in the retention of both products, but that public opinion / speculation has tainted the adoption and usage of SCCM to its detriment.

SCCM remains a top-tier management solution. Intune is a hugely powerful modern management solution. Combined, there’s huge potential for a “best of both worlds” approach which is clearly Microsoft’s aspiration for the enterprise. Modern Management doesn’t have to mean clearing out all that’s been before. By harnessing the power of the cloud, and overlaying it elegantly on the trusted, enterprise-ready architecture of SCCM they might have just convinced me that there’s life in the old dog yet!

RIP SCCM. RIP Intune. Long live Microsoft Endpoint Manager!

Microsoft Ignite has finally arrived! After months of build-up, the week is finally here… and what a week it’s going to be! I’m planning on posting throughout the week on social media. I’ll also be doing my best to post regular updates on here covering my thoughts, and the key things I pick up from the sessions I attend. As a pre-cursor , I thought I’d take 30 minutes to provide a handful of the sessions (and things!) I’m most looking forward to…

Session 1: Microsoft Cybersecurity Summit

The Security Summit is one of this year’s pre-day workshops (PRE28). Unsurprisingly for regular visitors of this blog, this is right up my street. The agenda took my fancy from the outset, more so having received the full breakdown:

• 08:00-09:00: Pre-Day Workshop Breakfast
• 09:00-10:00: Opening Keynote
• 10:00-12:00: Cybersecurity Industry Talks
• 12:00-13:00: Pre-Day Workshop Lunch
• 13:00-14:45: Afternoon Breakout Sessions
• 15:00-18:00: Afternoon Breakout Sessions
• 18:30-21:00: Cybersecurity Summit Dinner

For the first afternoon sessions, I’ve elected for one on learnings / approaches from Microsoft’s Cyber Defense Operations Center, and another on the removal of passwords. For the second part, I’ve chosen a hands-on session: “Into the Breach: A Microsoft Cyber Defence Experience”. I’m hoping to learn a huge amount from these sessions, in addition to putting some faces to the names of many of the people I interact with on Twitter (and some more, no doubt!).

I particularly like the “conference” nature of this pre-day. Nice and varied with a good mix of context, opinion, and technical content. There are also some fantastic speakers lined up. I’m confident there will be more to follow on this session…

Session 2: Microsoft’s Roadmap for Security, Compliance, and Identity

Perhaps three of the most used words on this blog, and the name given to the Technical keynote for Security. Who’d have thought?! There’s very little background detail on the Ignite session page (TK03), but I have high expectations! The likelihood is that this session will provide context to the various security announcements that will take place during the rest of Microsoft Ignite. It will also play a huge part in setting the focus areas I take forward when it comes to security over the next 12 months or so.

Much like the Security Pre-Day workshop, my attendance at this session shouldn’t come as much of a surprise 🙂 As I’ve alluded to previously on this blog, Security has been a real area of interest for me throughout my IT career. It’s also representative of many of the concerns that organisations have when it comes to adoption (or lack of!) of Microsoft Cloud. Microsoft have made huge strides in this area over the last couple of years. I see no sign of that letting up, and I’m hugely excited to see and hear about what Microsoft has for 2020 and beyond.

Session 3: Modern Management

This session is two-fold for me (BRK008). For one, I’ve always followed the work of Brad Anderson, but I’ve never had the opportunity of hearing him speak “live” (as it were!)… cue awkward fanboy moment! 😉 I also have a genuine interest in device management. My colleague Colin Macandrew and I delivered a session on the concept of Modern Management at Future Decoded just a few weeks ago.

For me, there’s an intrinsic link between legitimate “modern” management, and data / organisational security. The way that organisations can now leverage solutions like Intune to manage devices irrespective of type or location is truly incredible. Certainly in contrast to options available just a few years ago. Coupled with increasingly tight integration across the identity and data security stack, Modern Management of devices is every bit as important as anything else you might be focussed on when it comes to infrastructure.

When you layer other advantages; mobility, device freedom, and end user perception, a modern management strategy can be game changing. I’m really looking forward to hearing the Microsoft story on Modern Management. I’m also hopeful there will be a nod (or two, or three!) to some new capabilities coming to M365 soon. Depending on the content in this session I sense I might be making some changes to my schedule for the rest of the week!

Session 4: Investigate and respond to events with Azure Sentinel

This session (WRK033 is particularly close to my heart. One of my first posts on this site related to the (preview) launch of Sentinel. It’s since come of age, exited preview, and is the subject of a bunch of sessions at this years Microsoft Ignite. This is one of the earlier sessions of the week.

From a personal perspective, I’m keen to hear Microsoft talk about the product. Much of my opinion and commentary has been based on personal interpretation. Listening to the product team discuss the approach they expect people to take when it comes to threat investigation will be really insightful.

I’m hopeful the session will touch on some of what’s coming. Alert response through automation in particular. I’m also looking forward to learning more about investigation using some of the in-built capability, and picking up some best practices around real-world the use of Sentinel. Again, I anticipate this session may lead to some schedule changes as the week progresses!

Session 5: Azure Active Directory: New features and Roadmap

Another key theme of this blog is Identity. I’ve posted on multiple occasions about the importance of Identity driven security, and no doubt will again in the future. This session (BRK2130) should inform some of those posts, setting the agenda for Azure AD through 2020.

As an organisation, we like to think we’re at the forefront of the drive to secure Identity. We work closely with the product team at Microsoft, and drive an identity-first approach in all the M365 work we do.

Notwithstanding, many organisations fail to grasp the importance of “doing identity right”. Part of that is a lack of awareness / knowledge, but as much a factor is perceived complexity and impact to users. Microsoft have made huge strides towards minimising this, but there is evidently still work to do. Azure AD is one of the most underrated products in the Microsoft Cloud portfolio. I’m really looking forward to taking some of the outputs from this session forward to our customers. Expect further blog posts on this topic. It’s not going away… 😉

Oh, that, and I’m also super excited to hear Alex Simons speak! 😀

There are so many other sessions I could write about in this post. My session scheduler looks like an impending car crash, but the reality is that I plan (and intend) to get as much out of this week as I possibly can. There is so much to learn, and so much innovation happening in this space - much of which remains a mystery to those organisations who should be using it.

I’ll be posting as regularly as I can this week. Expect some further blog posts, and a barrage of content from my colleagues at #TeamTransparity.

Microsoft Ignite. Bring it on! 🙂

I thought the day would never come! Since it’s announcement at Microsoft Ignite last year, I’ve been waiting patiently for this feature to make a pubic appearance. The initial indications we by the end of last year, then Q1, then Q3… finally this week, Staged Authentication Rollout made its way to Public Preview.

I thought I’d post a brief introduction to the feature, following the theme of my previous “Snippet” on the GA of Windows Virtual Desktop.

Why the Hype?

For those that aren’t aware, I highly recommend you have a look at this session from Ignite last year. Skip to the 16 minute mark for an overview of the feature. In essence, Staged Authentication allows you to migrate users from federated to cloud authentication in a phased manner. To date, this transition has been a global one, set at the domain level using either Azure AD Connect, or PowerShell. Whilst it’s a low-impact change if everything goes to plan, the “big-bang” nature (naturally) introduces concern for larger organisations. This is exacerbated when you consider associated features that might be enabled at the same time; Conditional Access, MFA, Self-Service Password Reset etc. The prospect of thousands of users needing to enrol into these services simultaneously is a daunting one for Service Desk teams.

How Does Staged Authentication Rollout Work?

Once enabled, Staged Rollout appears in your Azure AD portal under the Azure AD Connect blade:

If you navigate to the feature, you’ll see a handful of options you can enable. Staged Rollout supports a transition to either Password Hash Sync (PHS), or Pass-Through Authentication (PTA). You can’t use the tool to implement a mix of both (for testing or otherwise). Microsoft’s guidance is to pick one, migrate, and then cut-over fully once all users are staged. The process of doing so is simple:

• Configure Azure AD Connect for PHS / SSSO or
• Deploy PTA Authentication Agents / SSSO
• Enable the relevant service option (PHS, or PTA)
• Add Users to a corresponding group, and assign this to the policy
• Test Sign-In using a staged account

The change should take place immediately, with any associated MFA / SSPR activity triggered at next logon for your test / migrated users. On completion (or when the bulk of your users are transitioned), you can make the global change to disable federation for your chosen domain.

Fuller documentation is available on the Microsoft Docs site here.

Obviously the feature is in Preview, and with that come the usual caveats. Support will be limited, and the experience may well change before this becomes Generally Available. All of that said, we’ve been involved in several projects recently that have leveraged this feature in a Private Preview capacity. In each case, it’s use has been flawless.

In Summary

There’s a broader question around whether you should transition away from ADFS. I hold some fairly strong views on that which I’ll put into a dedicated post when I get a moment. Regardless of your opinion this is a much-desired feature that’s hugely advantageous for larger organisations. If you federate today and are considering moving to Cloud authentication you need to take a look at this feature… I guarantee it will remove some of the nerves you might have around the change!

Happy playing! 🙂

A Content Delivery Network (CDN) is a sure-fire way to improve the performance of content accessed globally. For a while now I’ve contemplated using one; both to improve the performance of this site, and as an opportunity to experiment with Azure CDN. On the back of a Twitter conversation with a colleague Dale / @blackforce, I decided today was the day I’d take a look at configuring Azure CDN 🙂

Why now?

The back-story to this is a minor tale of woe. When I set up this site, I did so (being a “Microsoft guy”) using Azure Ap Service. Simple, reliable, and nicely scalable as things grow. In doing so I also used Let’s Encrypt to provide the site’s SSL certificate. The obvious advantage of Let’s Encrypt is the fact that they allow you to generate certificates for free… The caveat is a short life-time of 90 days. This would be a pain if they didn’t provide mechanisms for automating the request / renewal of site certificates. Fortunately they do, and in the case of Azure App Service this takes the form of an extension.

For the last 6 months or so this has worked like a charm. Come renewal time the extension pings a request off to Let’s Encrypt, renews the certificate, and then applies it to my site. In the most recent case, this didn’t happen, resulting in my site reporting an SSL error to visitors for a few days before I noticed 🙁 The fix was simple. The extension needed an update and I just needed to apply the update before triggering a manual renewal. Job done, certificate goodness restored! 🙂

When I posted about this on Twitter Dale pointed me at Cloudflare as an alternative, with the added benefit of them providing CDN services. Now, I do use Cloudflare on another site I’m involved with for just that. For the most part it’s fantastic, but I do have some mild gripes with the way they implement their free SSL service. The CDN point is valid though, and prompted me to get on and take a proper look at Microsoft’s offering. I went through the motions of configuring Azure CDN today and figured I’d jot some thoughts down into a post on it’s implementation…

Enabling CDN for App Service

Unsurprisingly, Microsoft make the process of adding CDN capabilities to sites hosted in App Service super simple. Equally unsurprisingly, there are some caveats and things to be aware of in the process…

As a starting point, it’s possible to configure the CDN independently of the App Service. Triggering creation from inside the App provides some advantage though, in that some settings are pre-configured. You can find the option to enable CDN within the Networking section of your App:

Selecting the “configure Azure CDN for your app” link leads on to a simple wizard with a handful of fields to complete. If you already publish your site externally and have configured SSL there are additional steps to consider. I’ll cover those later on in this post. Initially though you will need to provide:

• The name for the CDN profile
• Your choice of pricing tier (Microsoft, Akami, Verizon, or Premium Verizon - see below for further information on this)
• The public CDN endpoint name (this presents on “azureedge.net”, but we can assign a custom name later on)
• The “Origin Hostname”. This is the host that provides the content to the CDN, and will be pre-populated if you’ve initiated creation within the App Service

In the case of the “Origin”, the “azurewebsites.net” address assigned to your App Service will be used by default. This will be invisible to users accessing your site, who will interact with a hostname that resolves to the CDN. Using this default configuration SSL is maintained end-to-end should users need to communicate with the App Service directly after CDN is enabled. You can change this address later should you wish, but be conscious of maintaining end-to-end SSL if you do.

Configuring Azure CDN

Once the CDN has been created you will fairly quickly be able to access your site using the new “azureedge.net” address. This isn’t immediate and can take up to a couple of hours according to documentation. In my case, it was around 30 minutes before things kicked into life.

A point I said I would come to relates to the tiers of service. Azure CDN isn’t as simple as on / off. There are considerations around the type(s) of content you will be distributing which will have a bearing on which of the options is best for you. I highly recommend reviewing this link which provides a detailed overview of the functionality within each “flavour” of Azure CDN. In my case, I opted for “Standard Verizon”. This provides the best mix of features for the content I’m likely to be hosting, whilst also supporting an upgrade to Premium should additional rule customisation, or reporting become a requirement. I won’t go into detail on the different editions within this post, but would be happy to provide some additional commentary / feedback on each if needed - just contact me via the comments.

As far as configuration is concerned, there are a handful of things you will want (and are able) to do once you’re up and running. Initially, review caching rules. Caching rules allow you define exceptions for content that is best served directly from the host. In my case, I’ve excluded paths relating to sign-in and administration by specifying that they should bypass the cache:

You’ll also want to review “Custom domains”. This section allows you to bind hostnames that you own to the CDN service. To do this, you need to add each domain name, validating ownership as through the creation of CNAME records. These resolve to the azureedge.net CDN address, and will remain in place on completion:

A word on SSL

Much like Cloudflare, Microsoft allow you to enable SSL on custom domains. This is an inclusive service (in the context of paying for CDN), with certificates issued by DigiCert. Subsequent processing and renewal of certificates is managed by the CDN service.

The astute of you will have noticed the “pending” nature of my HTTPS status in the above screenshot. Where you elect to use Microsoft issued SSL certificates, expect a wait. Potentially a long one (up to 24 hours, assuming no issues based on my reading). In the case of a live site this is obviously disruptive and needs to coincide with a maintenance window. The CNAME records for your custom domains need to resolve to the CDN for the validation to succeed.

As I write this, I’m awaiting validation of my domain certificates. I can access my site using an alternative SSL secured custom domain (which I’ve chosen to use for my “Origin” address). I can also access using my App Service’s “azurewebsites.net” domain. Those visiting my site on my usual URL’s in the meantime will be seeing a certificate error… which isn’t ideal. Update: This process took around 14 hours to complete in my case…

Obviously this is a one-time thing, but is a nuisance none the less. You can avoid this by using / uploading your own SSL certificates, but that obviously carries a cost vs. using the integrated service from Microsoft. A minor complaint in an otherwise straightforward setup.

In conclusion…

I was surprised at the simplicity of CDN configuration within Azure. My experience has been focussed on App Service integration, but the steps and points mentioned are universally applicable. Azure CDN is a really straightforward service, as it should be to compete effectively with others.

The shine has been removed slightly for me with the delay in SSL validation. That aside, it’s doing what it should do. Page load times are reduced (based on some initial testing), performance for those accessing overseas should be improved, I have enhanced DDoS protection, and I (almost) have a free SSL solution to boot. Great success!

I haven’t made reference to pricing. Obviously Azure CDN isn’t a free service, but it is a comprehensive one. For those interested, pricing is available here. For all “standard” options, a tiered pricing structure based on data served is used. This is also true of the “premium” offering, albeit at an inflated cost. I’ll be continuing to use CDN for at least a few months, if not permanently, to gauge it’s effectiveness. Feel free to contact me for an update if / when you read this if interested.

I hope you’ve found this post useful. As always, feel free to contact on Twitter if you have any questions or feedback. It’s always welcome!

This is going to be slightly different in nature to my regular posts. A format I’ve been toying with adopting for a while now is a “quick take” on key news, announcements, and events. I really enjoy writing my regular posts, but they take a while to pull together. It’s not always feasible to provide timely commentary in the way I’d like. It’s also not always necessary to provide lengthy opinion pieces, or extensive technical detail…

I hope to address that with “Snippets”. These will be focused, brief (ish!?) posts on topical subjects that I want to respond to quickly. They won’t replace my usual posts, but I hope they will be more regular, and responsive to key industry news.

Welcome to Snippet #01, covering the General Availability of Windows Virtual Desktop (WVD) which was announced this last Monday..

WVD: The Good & The Bad

I’ve written about WVD previously, Microsoft’s response to the managed desktop. Having waited fairly patiently for its release, I was surprised to see it exit preview without warning last week. This was made all the worse given it was a day before Future Decoded, where we had a session planned on WVD… none the less, now that it’s out what’s new? What’s changed? Here’s a quick take of the highlights, and low-lights from my perspective…

The Good

• WVD launched alongside AppAttach. This supports real-time attachment of applications to a managed desktop, minimising the need for custom images.
• FSLogix technology is integrated into the WVD experience and licensing model. This provides full support for Office 365 in a virtualised desktop, and dramatically simplifies profile management.
• AV Redirection was simultaneously announced, with support for WVD. This reduces voice and video encoding through the use of WebRTC to enhance VDI performance.
• The “Windows Virtual Desktop Experience Estimator” provides a real-time view of the round trip time to each WVD supported region, aiding resource placement.
• The service attracts an SLA of 99.5%

The not so good… (I’ll refrain from using the word bad!):

• A management UI is still lacking. All administration tasks are completed via (RDS) PowerShell. A “sample management interface” built on an Azure Web App can be deployed for those itching for a GUI.
• Resources still need to be assigned to individual users. Active Directory Groups are not yet supported.
• Automatic scaling of host pools isn’t yet available. Azure automation routines can go some way to mitigating this, but a truly elastic WVD environment continues to be a desire… Microsoft are not (yet) financially backing the stated SLA

Obviously Microsoft will continue to mature the WVD offering. It’s very evidently going to be a central part of the application delivery story, and will go a long way to mitigating the constraints some organisations face with publishing legacy applications. In spite of its limitations though, WVD is a very solid v1 and well worth a look.

I’ll provide further detail on some of the new WVD functionality in due course, and will continue to monitor its progress. In the meantime though, feel free to get in touch via the comments selection below, or via Twitter with any questions.

Passwordless Authentication is a topic I’ve been keen to write about for a while now. Last weekend I finally managed to grab some time to get to grips with one piece of the passwordless puzzle I hadn’t had a chance to play with: YubiKey.

The concept of “passwordless” doesn’t really need explaining… the clue is in the name 🙂 It is something that’s had a lot of press in recent months though as it’s matured to the point of being near GA for Azure AD. When exactly it will exit preview is anyone’s guess… but I’d speculate an upcoming industry event may yield some news! Irrespective, it’s highly relevant and exciting functionality that has the potential to siginificantly reduce the risk of data breach through poor password practice.

Before we get into some detail, why is passwordless such a big deal? I spent a bit of time covering the concept in a theatre session I ran this last week at Future Decoded. A “problem” I think we all accept relates to use of (specifically bad practice with) passwords. Regardless of how much education goes into encouraging good password practice, the reality is that:

• People will often re-use passwords between different services.
• Variants of the same password are frequently used to get around password age or complexity requirements.
• Weak or default passwords are regularly exploited by attackers.
• Passwords are frequently exposed through data breaches, stolen / leaked credentials, or phishing attacks.

In 2019, passwords simply aren’t enough. They need to be supplemented by solutions like multi-factor authentication, or biometric verification. Ideally access via password alone should be eradicated altogether. Here’s where passwordless authentication steps in, replacing traditional passwords with a modern alternative to verify identity.

What are the Options?

There are several routes to implementing passwordless sign-in available already:

Whilst these don’t (yet) lead to a state where users are truly passwordless, it does mean that use of the password can be minimised. This can, in turn, lead to a place where much more robust password policies can be implemented without upsetting end users.

Many of you will be familiar with Windows Hello which uses device hardware to identify and verify a user login attempt. The issue with Hello is the need for specific (and often expensive) hardware to ensure the appropriate level of security. Integrated cameras with near infrared (IR) imaging capability, or high-quality fingerprint readers aren’t always incorporated into company procurement strategies…

An alternative is Microsoft Authenticator based passwordless sign-in. This has been in public preview for some time now. When deployed via the authenticator app, a passwordless policy prompts users to verify one of three numbers in place of supplying a password during sign-in. Coupled with biometric authentication on the authenticator app itself (e.g. TouchID, or FaceID on access), this provides a trusted mechanism for verifying the user identity without the need for password entry. It also satisfies MFA is this forms part of your Conditional Access strategy. This is a simple, low-cost solution to passwordless, but has the potential to be resisted in some organisations by users who object to installing a work application on a personal phone. In organisations where company devices aren’t issued routinely, this can be a barrier to it’s use. It surprises me to this day that individuals take issue with this… but there you go…

This brings me on to YubiKey.

YubiKey Passwordless Authentication

YubiKey is built upon Azure AD’s support for FIDO2 security keys (also in Public Preview). These devices allow sign-in using a physical device assigned to a user profile in tandem with a PIN number. When configured, Azure AD users can sign-in to both devices, and web portals without needing to specify a username or a password. Crucially for businesses, this also provides a mechanism for passwordless without expensive hardware, or the imposing of a mandatory mobile app.

So how does it work in practice? Let’s take a look through a typical example using the Office 365 web portal. When accessing portal.office.com, you will notice a new “Sign-in options” link below the username prompt. Clicking this link will present the following screen:

Selecting the “Sign in with a security key” prompt will trigger a request for the user to insert their security key:

Once inserted, a PIN number known to the user (and configured during key registration) is also required to verify the user identity:

Finally, we are prompted to touch the key to continue. This completes the sign-in process and we’re in… no username, and no password. A joy!

Pre-requisites for FIDO2 Passwordless Authentication

So how do we achieve password-less sign-in with a YubiKey? Let’s start with the pre-requisites. You need to have a supported FIDO2 key. I’ve based this post on YubiKey (from Yubico) who are perhaps the most well known, but there are others. A list of supported vendors is available on the Microsoft Docs Passwordless authentication page. You also need to ensure:

• Users in-scope are registered for Azure MFA
• Users are assigned to the combined MFA / SSPR registration preview
• Windows 10 1809 or higher is installed (1903+ preferred)

The latter point is applicable to both Windows sign-in, and web sign-in where Microsoft Edge on Windows 10 1809 (or higher) is required. It’s worth noting that the new Chromium based Edge browser is also supported.

Your tenant will need to have the “Use security keys for sign-in” setting enabled within Microsoft Intune > Device enrollment > Windows enrollment > Windows Hello for Business > Properties (Windows Hello for Business is not a pre-requisite however).

The combined MFA / SSPR experience can be found under User Settings > User feature previews within the Azure AD portal. It can be enabled for all users, or a subset of test users within an Azure AD Security Group:

Configuring FIDO2 Security Key Sign-In

Once the pre-requisites are in place, you can enable your Windows devices for FIDO2 security key sign-in. Note, this step enables Windows sign-in, and is not required for web authentication via security key. The easiest way to configure this is via Intune:

1. Sign in to the Azure Portal
2. Browse to Microsoft Intune > Device configuration > Profiles > Create profile
3. Configure the new profile with the following settings
   1. Name: Security Keys for Windows Sign-In
   2. Description: Enables FIDO Security Keys to be used during Windows Sign In
   3. Platform: Windows 10 and later
   4. Profile type: Custom
   5. Custom OMA-URI Settings:
      1. Name: Turn on FIDO Security Keys for Windows Sign-In
      2. OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
      3. Data Type: Integer
      4. Value: 1
4. This policy can be assigned to specific users, devices, or groups

We then need to enable our test users for FIDO2 security key sign-in. Navigate to Azure Active Directory > Security > Authentication methods > Authentication method policy (Preview). In here, modify the properties of FIDO2 Security Key to target your test accounts:

The final step is to register a Security Key against the user. This is completed using the new “My Profile” administration portal under the context of the user. Click through to “Security Info” and select the option to add a method. In the resulting prompt, select “Security key” and follow the registration wizard through to enable the key against the account. This will include the creation of a security PIN for the device.

On completion, you’re done! You should be able to successfully authenticate using your security key via a browser. You will also be able to choose the “FIDO2 Security key” option at the Windows login screen once your Intune policy has applied.

Conclusion

Passwordless sign-in, irrespective of your chosen route is a huge step forward in securing authentication for your users and data. Whilst the underlying password is still present on the user object today, I foresee a time where its only purpose is to provide initial validation ahead of strong authentication setup. I’ve been using passwordless (in all three of its forms) for the last year or so now and I wouldn’t dream of going back… Do I know my password? I think so…(!) Do I want to have to enter it at every logon vs. pushing a button, or staring at a camera? Not a chance.

I suspect for most, Windows Hello or Microsoft Authenticator will be the preferred route for passwordless. The addition of FIDO2 to the stable is a nice touch for those organisations struggling to accomodate specialist hardware, or user on-boarding via BYOD MFA. Whatever your preference, I’d encourage you to take a look at passwordless. It’s a revelation for the end user… 🙂

I saw a tweet earlier today from Alex Weinert (Director of Identity Security at Microsoft), drawing attention to a post that was published yesterday on the Exchange Team Blog. The post highlights some changes being made to the authentication model for Exchange Online, building on a previous announcement from last year. To repeat Alex’s words, it’s a huge deal. It’s also very good news from a security perspective.

Back at the beginning of last year Microsoft announced that they were going to deprecate Basic Authentication for Exchange Web Services as of October 2020. This will actively block connections from legacy clients that don’t support Modern Authentication. Yesterday’s post extends that deprecation to other Exchange services including ActiveSync, POP, IMAP, and Remote PowerShell.

What’s Basic Authentication?

Basic Auth (also referred to as Legacy Authentication) has been around for years. In simple terms it requires that a username and password combination be transmitted to an application with each request. This renders a users credentials vulnerable to interception (when not transmitted securely), and leaves services open to brute force or password spray attacks. You can read more about these types of attacks here.

By contrast, Modern Authentication is based on OAuth 2.0. Rather than sending credentials with each request, the authentication process results in the issuing of an access token. This token can be time limited and granted to specific applications or services. It’s also easily integrated with other security measures such as Conditional Access and Multi-Factor Authentication. It’s significantly more secure, and a key element in the step towards intelligent security that enables context aware decisions to be made on devices and users accessing company information.

Great, you might say… why don’t I (or Microsoft) enforce it everywhere already? Well, there’s a catch. Not all clients are supported. You need to take steps to ensure you are prepared.

What should you do?

You could wait for next October. The 13th to be precise. Hope for the best, and assume nothing will break. For obvious reasons, that’s not a stance I’d advocate…

There’s a good chance you’ll know if you have a significant problem when it comes to your client estate. Obvious concerns aside, you’ll need to consider applications that authenticate directly against Exchange Online to ensure compatibility. Additional tools will be made available in the near future to aid the identification of users still utilising Basic Auth.

If you know you’re in a good place you can take steps today to block Legacy Authentication, ahead of time. This is advantageous in terms of readiness, but more importantly will enhance your security posture immediately. With Basic Auth disabled you ensure that Conditional Access policies designed to enforce MFA cannot be circumvented. You also reduce the risk of compromise through some of the password attacks referenced previously.

You can enforce Modern Authentication in a couple of ways. One option is to adopt custom Authentication Policies in Exchange Online. These can be applied to specific users to support testing, and also provide the flexibility to block Basic Authentication against specific protocols. Useful if you have a short-term need to retain it for certain systems. Microsoft have published an excellent guide for disabling Basic Authentication in Exchange Online which covers this approach in detail.

An alternative approach is to block via Conditional Access. I made reference to a number of new baseline policies in a recent blog post, one of which is aimed specifically at this problem. By enabling the “Baseline Policy: Block Legacy Authentication&” policy, you can enforce Modern Authentication for all users:

Custom policies can achieve the same thing, with a little more flexibility.

SMTP Authentication

An exception to Basic Authentication which I haven’t addressed (that may have been ringing some mental alarm bells), relates to SMTP. Many peripheral devices (scanners, monitoring devices etc.) rely on Basic Authentication for mail transition. This will continue to be supported for SMTP, with further updates on this due soon from Microsoft.

Hopefully this has proved a useful read. The move away from Basic Authentication for these protocols is a significant one, but is a positive move from a security perspective. Whilst there’s the potential for some disruption, there’s also ample time to prepare and transition to Modern Auth over the next year. The end result will be a dramatic reduction in the likelihood of authentication based compromise.

Feel free to get in touch if you have questions, or want to know more. Good luck with your own implementations!

A fairly topical post today in response to yesterday’s news that Twitter CEO Jack Dorsey’s account was “hacked”. I use that term loosely as it’s since transpired the method used was actually the SIM swap scam (explained further below). None the less, it serves to highlight the importance of account security and should be a reminder to us all of the lengths that “hackers” will go to. Particularly for those in the public eye. I thought I’d take a moment to run through some simple steps you can take to enable the Microsoft Authenticator app to be used for securing Twitter.

A caveat…

It’s important to note that in this example the “weakness” exploited was the text update system Twitter uses, not the account. Whilst most of us are used to app / web based consumption of Twitter, the text system is still widely used in developing countries. Using this method you can tweet by sending an SMS from your registered mobile number - no sign in required. Here Jack’s number was ported to a new SIM and intercepted, allowing the perpetrators to circumvent traditional security measures. Crude, but actually quite simple - and clearly effective 🙂 Whilst the steps outlined in this post don’t prevent this form of exploit, they’re every bit as important. They’re also simple, and dramatically reduce your likelihood of becoming a victim.

What can you do?

As you’ll have noted by now, a recurring theme of this blog is security. I’ve talked in various posts about features in Azure AD like Conditional Access to enforce multi-factor authentication (MFA) on sign-ins to Azure AD. This is all well and good for business applications, but what about personal accounts or services? We increasingly see MFA recommended everywhere. Email accounts, banking, social media applications, websites. What few realise though, is that it’s possible to condense the number of methods used.

Do you really need 5+ mobile apps to prove who you say you are? I did, not too long ago. I now have 2… (and only then because HMRC insist on using their own application 😬).

In this post I want to focus on securing Twitter using the Microsoft Authenticator - for two reasons:

• Lots of people are vulnerable to account compromise due to not having MFA enabled for Twitter
• Where MFA is turned on it defaults to SMS validation… which just feels a bit 00s 😉

Configuring Twitter MFA to use Microsoft Authenticator

Configuring Twitter to use MFA via the Microsoft Authenticator is really simple. As a pre-requisite you need to have verified your mobile number and email address. I’m also going to assume that you have the Authenticator app installed on your mobile. Screenshots below are taken from an iOS device, but will look similar on Android for those of you on the dark side 🙂

In the Twitter app, navigate to Settings and Privacy > Account. Assuming you’ve verified your Phone / Email details both will be populated. Select “Security”, and then “Login Verification”. Your app will most likely look like this:

Toggle “Login Verification” to on and you’ll be asked to confirm acceptance that you’ll need your phone to sign in to Twitter. You’ll then be walked through a short wizard to enable SMS codes (initially) during which you’ll need to verify your current Twitter password and mobile (via SMS). On completion I strongly suggest you generate a Backup Code when prompted. This will be your only route in should you lose your phone, or access to your Authenticator app… you have been warned!

Once finished, Login Verification should look as follows:

Here’s where we’re going to integrate Microsoft Authenticator, and optionally disable SMS. Toggle “Mobile Security App” to on. Another wizard will launch to walk you through activating your Authenticator app for Twitter. After clicking “Set up Now” you’ll be redirected into Microsoft Authenticator. You should now see a Twitter entry and corresponding code:

To complete setup, verify that the code functions by entering the current digits back into the setup wizard. On redirection back into the Twitter app you should see that “Mobile Security App” is enabled. You can choose to disable SMS notifications if you wish, at this point:

From this point onwards, whenever you login to Twitter you’ll be asked to verify your identity using the code from your Authenticator app. Sadly this doesn’t extend to push notifications (at this point in time).

Summary

Obviously securing Twitter is one example of many. There are multiple services that let you use your own authenticator app(s) in place of SMS or default code generators. For me, securing as many of my online services as possible via MFA is a no-brainer. If I can then consolidate them into a single (or a handful) of apps in lieu of text messages / phone calls / proprietary applications, then so much the better ?

The bottom line is simple. Whilst the majority of us aren’t targets in the way that individuals like Jack Dorsey are, we bear our own responsibility for securing our online identities. In most cases this can be done simply, and using tools / devices that are already at your disposal.

Don’t become a victim!

I’d forgive you if you thought that I’d shut up shop and abandoned this blog altogether… it’s been a while since I last posted. I’ll be honest, I hadn’t realised quite how long it had been until I reviewed the date of my most recent post this week. Two weeks without any content is bad enough. Nearly two months is quite unforgivable ? So, time for an update.

First, an apology. Second, an (attempted) explanation.

An Apology…

It was always my intention for this blog to be a steady stream of information, news, and experience from my day-to-day encounters with Microsoft Cloud. I’m at the (relative) bleeding edge of all things Microsoft, it seems a shame to waste that by not shouting about the things I love, and get involved with, as much as possible. Naturally though, that “day-to-day” gets in the way on occasion(!). Balance is a fine thing, but it’s not always difficult to juggle the demands of work / home / family / rest / play…

The reality is that I just haven’t had the time (or motivation) in recent weeks to get content finished and up. Yes… I can hear that violin too! ?

On a personal level, I enjoy the challenges of time-management, self-discipline, continuous development etc. I spend a portion of my time reading books and articles that focus on " bettering" myself. With hindsight, I’ve considered this site a side-project more than a priority to date. This is something I want to remedy moving forwards, putting some of those principles into practice here. I’d welcome anyone reading to direct me back to this paragraph if I slip again… 😉

An Explanation…

Life has been crazy busy - both at home, and at work. Some of you will know that I had an update in my work life recently. Having previously worked in a Pre-Sales / Technical Lead capacity at Transparity, I’ve now take on the role of Head of Technology. Whilst that’s hugely exciting, managing old and new responsibilities during the ongoing transition has led to some long days. It’s also put pressure on time that would otherwise have been spent curating content for here.

We’ve also entered silly season for holidays, of which I include my own 🙂 We (the family and I) have just returned from a week in Portugal which led to some much needed rest. I didn’t give a thought to blogging, very little to tweeting, and took the opportunity to reset…

So… where are we now? Well, I’m hopeful that the peak of “crazy busy” is over. I’m also hopeful that the half-dozen or so part-written blog posts I have in my drafts folder will see the light of day soon. Next month (ish!) is Future Decoded here in the UK - I will be presenting at least a couple of sessions at that event. I’m also very much looking forward to attending Microsoft Ignite in November.

In short, I expect normal service to resume - at least soon. I have some great pending content, and more will follow post-Ignite. Thank you to those who have been visiting / reading posts - there’s been a consistent volume of visitors to the site. For those returning hoping to see new posts… stay tuned!

In my previous post on Azure Bastion I covered some of the basics around it’s addition to Azure. I touched on some of the reasons you might look to deploy Azure Bastion, and some of the advantages it brings in comparison to traditional solutions like RD Gateway, and jump-boxes. In this post, I want to build on that initial overview with a walk through of the deployment process. Azure Bastion is super simple to get up and running with. It’ll inevitably become another of those “must-have’s” for organisations as it matures…

Initially; some caveats. I referenced these in my overview of Bastion but for clarity they’re worth repeating here. At this point in time, the service is in Preview. All that really means is no SLA. Bearing in mind the ease with which you could work around it’s unavailability, it’s likely to be a non-issue… but it would be remiss of me not to highlight that “minor” technicality 🙂 It’s also only available in a handful of regions:

• West US
• East US
• West Europe
• South Central US
• Australia East
• Japan East

The above said, and on a positive note, Bastion is subject to a 50% discount during the Preview (see the Product page for more details on pricing). Even at full price it’s likely to be cheaper than alternatives, and significantly more secure than internet facing access.

Preparation

Before you can deploy Azure Bastion, you need to onboard the preview into your tenant. To do this, run the following commands in Azure Cloud Shell.

Register the feature:

Register-AzProviderFeature -FeatureName AllowBastionHost -ProviderNamespace Microsoft.Network

Re-register your subscription with the Microsoft.Network provider namespace:

Register-AzResourceProvider -ProviderNamespace Microsoft.Network

Verify that Azure Bastion is enabled for your subscription:

Get-AzProviderFeature -ProviderNamespace Microsoft.Network

It takes a few minutes for registration to take place. After running the first command you’ll note that “AllowBastionHost” will show a registration state of “Registering” (as opposed to “Registered”). Be patient. The documentation indicates that it will take “a few minutes”. In my case it took around 10 before the Microsoft.Namespace updated:

Deploy Bastion

Once enabled, you can deploy Bastion from the preview portal. Search in “All Services” for “Bastions”:

Click Create to launch the “Create a Bastion” wizard:

A point needing some explanation here is the subnet attribute (which appears once a Virtual Network has been selected). Much like a VPN Gateway, a dedicated subnet with a specific name is required. Create a subnet in your Bastion enabled VNet with the value AzureBastionSubnet. Microsoft’s recommendation is a /27 or larger address space, without assigned NSG’s, route tables, or delegations.

Once you’ve reviewed, and completed the required variables, click Review + Create to initiate the deployment. After 5 minutes or so, you should have a functioning Bastion instance! 🙂

Using Azure Bastion

Once the Bastion is deployed, you’ll be able to use it to access Virtual Machines in the associated VNet. Supported protocols are RDP (3389) and SSH (22) - both via browser over SSL. What this means in practice is that you don’t need (and actually, can’t use) client software on your local machine. This point is referenced in the Bastion FAQ, along with a list of supported browsers. These are (at the time of writing):

• Microsoft Edge
• Google Chrome (Windows)
• Google Chrome (MacOS)
• Microsoft Edge Chromium (Windows)
• Microsoft Edge Chromium (MacOS)

To establish the connection, click “Connect” icon in the properties of any Virtual Machine. Alongside the traditional RDP and SSH tabs, you’ll now see a “Bastion” option. Based on the VM Operating System (Windows, or Linux) RDP or SSH is assumed. For a Windows machine, enter RDP credentials. For a Linux host, you can enter traditional username / password values, or authenticate using a Private Key. The latter can be manually inserted, or uploaded via a local file.

Once initiated, the session will open in a new window (if selected), or inside of the Azure Portal. The experience is similar to that of browser based RDS, and performs surprisingly well:

Obviously there are constraints at this stage. Copy / Paste functionality is rudimentary, and the browser-based nature means that you don’t get feature parity equivalent to a network level connection. That said, support for local clients has been hinted at, which will address some feature gaps. We should also remember that it’s early days for the development of Bastion. I’m hopeful, and expectant, for some fairly significant progress in the coming months 🙂

Summary

I hope (if you’ve made it this far) that this post has been useful. I’d encourage you again to read through my previous post if you haven’t already, which provides some commentary and additional background to Bastion more generally. Also take a look through the Microsoft documentation which, in spite of it’s Preview status, is reasonably comprehensive 🙂

At the risk of repeating myself, I think this is a great addition to the Azure portfolio. It’s simple to deploy, low cost, and addresses a notable gap that existed when comparing Azure with other Public Cloud providers. Best practice isn’t always obvious or easy to achieve, but PaaS based services that promote a good security baseline are an excellent step forward in helping customers to do the right thing from the outset!

I’ve been waiting patiently for news on Azure Bastion since hearing it was in development a short while back. I wasn’t able to access the Private Preview, so news that it had entered Public Preview was a pleasant surprise!

Securely accessing IaaS workloads in Azure has always been cumbersome. If you have VPN access into your Azure environment(s) it’s a non-issue, but for isolated, or test and development workloads it represents more of a challenge. Mitigating the concern of public access via RDP / SSH with solutions like just-in-time (JIT) access is one option, but many resort to jump-box solutions which add administrative overhead and complexity.

There’s an array of good-practice documentation out there which can assist with securing administrative connections into Azure. Some of these focus on the notion of a hardened jump-box, others look at access management solutions like RD Gateway integrated with Network Access Protection (NAP). The common pitfall with these solutions is the human factor when it comes to setup. Coupled with the ongoing need to patch, update, and maintain…

Enter: Azure Bastion

The concept of a bastion host is a simple one. It focuses on the idea that a system can be designed to support specific internet-facing functions in a way which is secure. The principle is applicable to lots of workloads, but is particularly relevant to the jump-box concept (notably in AWS where the terminology has applied for a long time).

Azure Bastion is a PaaS service designed to support access to IaaS workloads via RDP and SSH; without a VPN or the assignment of public IP addresses 🙂 Deployed directly into your Azure virtual network, it supports web-based access over SSL. This negates the need for clients, and ensures access where firewalls might be blocking required ports… simplifying access in addition to being straightforward to deploy and administer:

I’d planned to include a “how-to” guide on deployment and configuration in this post, but time has escaped me today and I was keen to get this up while the news is fresh. I’ll post this soon, along with some “real-world” twists. In the meantime the folks in the Product Team have put an excellent deployment guide together. You can find this within the release documentation, specifically the “Create a bastion host” section here 🙂

Limitations

There are some short-term limitations to be aware of. Preview status means no SLA, and availability is currently limited to a handful of regions:

• West US
• East US
• West Europe
• South Central US
• Australia East
• Japan East

…on the plus side, Preview status also means cheaper, with 50% off until it enters general release 🙂

It’s also worth noting that single-sign on capability via Azure AD identities is coming soon. I’m super excited about this on the basis that this will extend support to include Azure MFA and, presumably, Conditional Access. Those of you that have read my previous posts (e.g. Conditional Access: New Baseline Policies) will know that Azure AD is a firm favourites of mine!

I’ve been excited for Azure Bastion since I first got wind that it was coming. At face value it’s a minor addition, but web-based RDP / SSL is a significant new capability, and the future integrations with Azure AD will unlock more opportunities for addressing a variety of use cases. I’m particularly keen to see whether it can be paired with B2B guest access. This could be game changing for MSP’s who need secure and simple remote management of customer infrastructure.

Time will tell… in the meantime, happy playing! Feel free to comment below with your thoughts – I’d welcome your feedback. Alternatively get in touch with me on Twitter 🙂

I seem to write an awful lot on here about Conditional Access… not that that’s a bad thing 🙂 As I’ve referenced before, it’s possibly one of my favourite Azure AD features and is a key part of the puzzle when it comes to securing, enforcing, and controlling authentication.

To date Conditional Access has been a notable gap in the small(er) business variant of Microsoft 365: M365 Business. Yesterday (at long last!), that changed so you can now take advantage across the M365 stack!

Conditional Access in M365 Business

In a blog post on the Microsoft Tech Community forums yesterday, Ashanka Iddya announced that effective immediately Conditional Access will be provided as part of Microsoft 365 Business. From a feature perspective, it will be equivalent to that in Azure AD P1. This is a HUGELY advantageous for those organisations that are serious about securing access, but don’t want (or can’t justify) the uplift to M365 E3. If it applies to you, take a look today… you’ve just been gifted a fantastic set of functionality that was sorely missing before!

I provided the below overview in a previous post on Conditional Access (CA: New Baseline Policies) which I’ve repeated here for those that are unfamiliar. Happy reading, and happy playing!

A bit about Conditional Access…

In my opinion, Conditional Access is one of those fantastic Azure AD features that almost single-handedly justifies the purchase of Premium licensing. For the uninitiated, it allows us to control authentication behaviour based on a selection of things…

At a base level, we can use Conditional Access to approve, block, or limit sessions based on different criteria. For Azure AD P1 these attributes are based on static conditions such as who / what / where. Azure AD P2 extends this to include risk-based policies – a component of Identity Protection. These advanced policies use automated intelligence to classify the risk of an authentication request; enforcing dynamic controls based on the result. As an example, a request from an anonymous IP address on an unknown device can trigger a high-risk condition; blocking access or mandating MFA before the request is allowed. Clever stuff.

Have a read of Ashanka’s post, and pay particular attention to the FAQ section at the base of the article. In there you’ll find extra detail, the limitations, and applicability.

Where it applies to you, I guarantee you won’t be disappointed!

Feel free to make contact in the comments below, or to contact me on Twitter if you have any questions 🙂

I’ve been particularly busy these last couple of weeks and struggled to find time to post on here. I do have several things saved up that I’m keen to get posted though… this being the first in a series of planned entries. For now, the Identity theme continues 🙂 I wrote about the Security Registration updates in Conditional Access a while back. Since then Microsoft have further improved CA - adding some new baseline policies that can benefit all environments.

I was keen to provide some commentary around these changes, hopefully encouraging you to take a look and enable them within your own tenants. Others have covered this already, so I’m a little late to the party. In my opinion though, you can’t shout loudly enough about some of these new security oriented additions.

So here goes…

A bit about Conditional Access…

Conditional Access is one of those fantastic features in Azure AD that almost single-handedly justifies the purchase of Premium licensing. For the uninitiated, it allows us to control authentication behaviour based on a selection of things:

At a base level, we can use Conditional Access to approve, block, or limit sessions based on different criteria. For Azure AD P1 these attributes are based on static conditions such as who / what / where. Azure AD P2 extends this to include risk-based policies – a component of Identity Protection. These advanced policies use automated intelligence to classify the risk of an authentication request; enforcing dynamic controls based on the result. As an example, a request from an anonymous IP address on an unknown device can trigger a high-risk condition; blocking access or mandating MFA before the request is allowed. Clever stuff.

So What’s New?

Conditional Access policies are a powerful weapon in ensuring your organisation’s security, but they can be unwieldy and confusing. What’s good? What should you be enabling? What’s best practice? Baseline policies are Microsoft’s way of highlighting the answers to some of these questions, the first of which was the “Require MFA for Admins” policy introduced last year. These have been added to in the last few weeks with a handful of new (Preview) additions:

• End User Protection
• Block Legacy Authentication
• Require MFA for Service Management

End User Protection (Preview)

The End User Protection entry takes some of the complexity out of configuring a (friendly) policy for MFA; drawing on some of the more advanced risk-based capabilities of Azure AD P2. In simple terms this policy invokes MFA where the user session is deemed to be a potential risk. It also ensures compromised accounts (where credentials have been detected via Microsoft’s leaked credential service) are proactively blocked. In this latter case access isn’t reinstated until the user resets their password via self-service password reset, or an administrator clears the risk alert by assigning a new (temporary) password.

I really like this addition. Aside from lending access to some of the more premium capabilities of P2, it simplifies the creation and maintenance of Conditional Access policies relating to MFA. Many policies I’ve seen errr on the side of caution, triggering unnecessary prompts for users that lead to irritation. At the opposite end of the scale, lots of organisations don’t leverage MFA enough to secure authentication. Why not let Microsoft do the work for you?!

As with most policies, you should exclude break-glass accounts to ensure access in case of any MFA / CA related outage (no references to recent events!).

Block Legacy Authentication (Preview)

The Block Legacy Authentication policy does exactly what it says on the tin. It’s no secret that most bad sign-in attempts come via legacy authentication requests. Given that this method provides no support for MFA it’s hardly surprising, but does mean that even with an MFA policy you are exposed to risk if legacy protocols are enabled.

The recommendation for some time now has been to disable these using existing Conditional Access controls. This new policy makes it that bit easier to do so 🙂 There are some prerequisites to be aware of though:

• Review Azure AD sign-in logs to understand the potential impact see here for a guide).
• If there’s evidence of legacy authentication in use, ensure your directory is enabled for modern authentication.
• Verify that connecting clients (Office, Mobile Apps / Devices etc.) in addition to Office 365 services are modern authentication enabled.

Once you’ve satisfied those requirements and confirmed that legacy authentication isn’t (widely) used, enable this policy to automatically block legacy authentication requests. Job done! 🙂

Require MFA for Service Management (Preview)

Last, but not least, we have the new “require MFA for service management” policy. This isn’t quite as obvious as the previous two in title, but is a useful and sensible policy to enable - irrespective of whether you extensively use services homed in the world of Azure.

An increasing number of organisations are turning to Azure to deliver services back to the organisation. Interaction takes many forms ranging from simple portal based activity, to programmatic integration via Azure PowerShell or the Azure CLI. In all cases the default sign-in experience is devoid of MFA - leaving your environment exposed to a variety of potential attacks.

This policy enforces MFA for all attempts to sign-in to these services - administrative or otherwise. For this reason, again ensure that break-glass or Service Accounts / Principals are excluded where you need emergency or programmatic access that can’t respond to MFA challenges.

These are excellent new baselines for what remains one of my favourite features of Azure AD. Whilst Conditional Access is fairly intuitive, it’s not easy for everyone to grasp, or to get “right”. Microsoft’s decision to start including these best practices out of the box is going to do wonders for the security of those organisations who want to “set and forget” - without the worry of whether they’ve adopted the multitude of options in the right way.

Here’s hoping for more of these as time goes by, and (dare I say it) automatic enablement as they mature…

Do heed the / my warnings around exclusions, and prerequisites if you haven’t done so already… That aside, enjoy spending 5 minutes turning these on to get yourselves (and your organisations) into a better place!

Edit (1st September 2020): This article relates to the original release of WVD. The Windows Virtual Desktop Spring Update saw WVD PowerShell support integrated into the (existing) AzWvd module in place of the RDS. Please refer to Set up the PowerShell module for Windows Virtual Desktop for details.

In my recent “Getting to grips with WVD” post, I made reference to the emphasis on PowerShell for administration. I had a few questions in response and was keen to follow that post up with this; a WVD PowerShell reference. Hopefully it helps those of you out there who are looking to deploy Windows Virtual Desktop (WVD).

I don’t intend to include a lot of commentary around this post. It’s not an overview of WVD, or a deployment guide, but should help those of you who have taken the plunge with WVD at this early stage. By way of background, Microsoft have committed to a management console in time for its GA release. In the meantime, the only interface available is PowerShell - useful to learn, but not overly friendly for WVD specifically. The good news is that those familiar with RDS administration via PowerShell will feel right at home… 🙂

Connecting to the Service

Use the following command to connect to the WVD service, entering credentials when prompted (work or school account):

Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"

A one time activity will be the creation of your WVD Tenant which is achieved by running::

New-RdsTenant -Name <TenantName> -AadTenantId <DirectoryID> -AzureSubscriptionId <SubscriptionID>

Working with a Service Principal

A Virtual Desktop Tenant “RDS Owner” account is needed for each Host Pool - this account is used to authenticate the pool to the WVD service. It’s likely you have MFA enabled for privileged accounts, in which case a Service Principal will be required.

The following commands are used to create the Service Principal:

Install-Module AzureAD
Import-Module AzureAD

$TenantGroupName = "Default Tenant Group"
$TenantName = "<Tenant Name>"

$aadContext = Connect-AzureAD
$svcPrincipal = New-AzureADApplication -AvailableToOtherTenants $true -DisplayName "Windows Virtual Desktop Service Principal"
$svcPrincipalCreds = New-AzureADApplicationPasswordCredential -ObjectId $svcPrincipal.ObjectId

Install-Module -Name Microsoft.RDInfra.RDPowerShell
Import-Module -Name Microsoft.RDInfra.RDPowerShell

Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
Set-RdsContext -TenantGroupName $TenantGroupName
New-RdsRoleAssignment -RoleDefinitionName "RDS Owner" -ApplicationId $svcPrincipal.AppId -TenantGroupName $TenantGroupName -TenantName $TenantName

Extract (and store securely) the Service Principal credentials for use in your Host Pool deployment by executing the command:

($svcPrincipalCreds.Value)

To validate the Service Principal can connect and access your WVD instance, use:

$svcPrincipalCredentials = New-Object System.Management.Automation.PSCredential($svcPrincipal.AppId, (ConvertTo-SecureString $svcPrincipalCreds.Value -AsPlainText -Force))
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com" -Credential $svcPrincipalCredentials -ServicePrincipal -AadTenantId $aadContext.TenantId.Guid

Get-RdsHostPool -TenantName <Tenant Name>

Creating & Managing Host Pools

Host Pools house the Virtual Machines that deliver resources, along with Desktop and RemoteApp Application Groups. Whilst provisioning is far better addressed through the Azure Marketplace (“Windows Virtual Desktop - Provision a host pool”), there are some useful cmdlets available for Host Pool management.

Create a new pooled WVD Host Pool:

New-RdsHostPool -TenantName <Tenant Name> -Name <Host Pool Name>

Create a new persistent WVD Host Pool:

New-RdsHostPool -TenantName <Tenant Name> -Name <Host Pool Name> -Persistent

Retrieve details for a specific Host Pool:

Get-RdsHostPool -TenantName <Tenant Name>

Modify the properties of a Host Pool to specify breadth-first load balancing:

Set-RdsHostPool -TenantName <Tenant Name> -Name <Host Pool Name> -BreadthFirstLoadBalancer

Modify the properties of a Host Pool to specify depth-first load balancing:

Set-RdsHostPool -TenantName <Tenant Name> -Name <Host Pool Name> -DepthFirstLoadBalancer

Creating & Managing App Groups

Application Groups determine the type, and detail of resources published to assigned users. They have a Resource Type designation of either Desktop, or RemoteApp, but not both. A default “Desktop” App Group will be created as part of Host Pool creation via Azure.

Create a new Desktop App Group:

New-RdsAppGroup -TenantName <Tenant Name> -HostPoolName <Host Pool Name> -Name <App Group Name> -ResourceType Desktop

Create a new RemoteApp App Group:

New-RdsAppGroup -TenantName <Tenant Name> -HostPoolName <Host Pool Name> -Name <App Group Name> -ResourceType RemoteApp

Retrieve the properties of an App Group:

Get-RdsAppGroup -TenantName <Tenant Name> -HostPoolName <Host Pool Name> -Name <App Group Name>

Publishing & Managing RemoteApp Applications

In the case of a RemoteApp designation, Application Groups need to be populated with RemoteApp applications.

Retrieve available apps from your RemoteApp App host virtual machine(s). WVD will interrogate your image and list the available Start Menu items:

Get-RdsStartMenuApp <Tenant Name> <Host Pool Name> <Application Group Name> | Select FriendlyName,AppAlias

An example of the output from the default Windows 10 multi-user gallery image is as follows:

FriendlyName                   AppAlias
------------                   --------
Access                         access
Character Map                  charactermap
Database Compare               databasecompare
dfrgui                         dfrgui
Disk Cleanup                   diskcleanup
Excel                          excel
Internet Explorer              internetexplorer
iSCSI Initiator                iscsiinitiator
Math Input Panel               mathinputpanel
Memory Diagnostics Tool        memorydiagnosticstool
ODBC Data Sources (32-bit)     odbcdatasources32bit
ODBC Data Sources (64-bit)     odbcdatasources64bit
Office Language Preferences    officelanguagepreferences
Office Upload Center           officeuploadcenter
OneDrive                       onedrive
OneNote 2016                   onenote2016
Outlook                        outlook
Paint                          paint
PowerPoint                     powerpoint
Project Server Accounts        projectserveraccounts
Project                        project
Publisher                      publisher
Quick Assist                   quickassist
RecoveryDrive                  recoverydrive
Registry Editor                registryeditor
Remote Desktop Connection      remotedesktopconnection
Resource Monitor               resourcemonitor
Snipping Tool                  snippingtool
Spreadsheet Compare            spreadsheetcompare
Steps Recorder                 stepsrecorder
System Configuration           systemconfiguration
System Information             systeminformation
Task Manager                   taskmanager
Telemetry Dashboard for Office telemetrydashboardforoffice
Telemetry Log for Office       telemetrylogforoffice
Visio                          visio
Windows Fax and Scan           windowsfaxandscan
Windows Media Player           windowsmediaplayer
Windows Speech Recognition     windowsspeechrecognition
Word                           word
Wordpad                        wordpad

To create a RemoteApp based on an installed application:

New-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name <Friendly Name> -AppAlias <App Alias>

By way of example, the following commands apply to the creation of the standard Office applications (Word, Excel, PowerPoint, and Outlook):

New-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name "Word" -AppAlias word
New-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name "Excel" -AppAlias excel
New-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name "PowerPoint" -AppAlias powerpoint
New-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name "Outlook" -AppAlias outlook

It’s possible to customise the command line parameters associated with a given application. For example, the passing of a command line argument to a web browser to launch a specific web page. This is achieved by specifying the “RequiredCommandLine” parameter of a published RemoteApp:

Set-RdsRemoteApp -TenantName <Tenant Name>  -HostPoolName <Host Pool Name> -AppGroupName <Application Group Name> -Name <Friendly Name> -CommandLineSetting Require -RequiredCommandLine <Additional Arguments> 

To list RemoteApp applications associated with a specific Application Group:

Get-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name>

There will also be occasions where you want to remove RemoteApp’s from an Application Group. To do this, run:

Remove-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name <Friendly Name>

Managing User Permissions to WVD Resources

Users need to be assigned to Application Groups within WVD. At present these need to be assigned explicitly using the following commands. The ability to assign permissions to groups is anticipated in time.

Permissions are applied to the Application Group, as opposed to specific resources (e.g. individual RemoteApp’s). To present different combinations of Applications to different users, multiple Application Groups are necessary.

Adding a user to an Application Group:

Add-RdsAppGroupUser <Tenant Name> <Host Pool Name> <Application Group Name> -UserPrincipalName <user@domain.com>

Removing a user from an Application Group:

Remove-RdsAppGroupUser <Tenant Name> <Host Pool Name> <Application Group Name> -UserPrincipalName <user@domain.com>

Managing User Sessions

As with more traditional RDS deployments, there will be occasions where the management of User Sessions is a requirement. We have a number of options available to us within WVD - many of which hinge off of the following command to list User Sessions running within a host pool:

Get-RdsUserSession <Tenant Name> <Host Pool Name>

Using the resulting Session Host, and Session ID information, we can invoke the following actions.

Disconnect a session:

Disconnect-RdsUserSession <Tenant Name> <Host Pool Name> -SessionHostName <Session Host Name> -SessionId <Session ID>

Log Off a user session:

Invoke-RdsUserSessionLogoff <Tenant Name> <Host Pool Name> -SessionHostName <Session Host Name> -SessionId <Session ID>

Send a notification to the user session:

Send-RdsUserSessionMessage <Tenant Name> <Host Pool Name> -SessionHostName <Session Host Name> -SessionId <Session ID> -MessageTitle <Title> -MessageBody <Message>

I hope you’ve found this WVD PowerShell reference useful. I’ll do my best to maintain it as Windows Virtual Desktop matures, and no doubt much of this functionality will make its way into the forthcoming Management Console.

If you haven’t already, I’d urge you to read my previous post which included some of the information in this post, along with a broader commentary on the features and functionality within WVD as a whole.

A phrase (perhaps) overly used in recent months / years is that of “User Empowerment”; that slightly cheesy phrase attached to services that hand flexibility and choice to end users in how they’re used. It’s also particularly true of Office 365, where features and services are released almost weekly that focus on user experience first, and administrators second. In many respects this shouldn’t be a surprise - it’s an intrinsic part of Microsoft’s mission statement after all - but that stance doesn’t come without issue…

An increasing challenge for many IT Departments is the proliferation of Groups that results from use of Microsoft Teams (in particular). Many accept just how fantastic Teams is at fostering collaboration, but the appearance of “Dave’s Test Group”, “Jane Personal”, and “Project Potato” in our Azure AD tenants doesn’t sit well with most. It’s also counter productive for those looking for useful Groups and Teams to join. Enter Azure AD Naming Policies - in existence for a while, but subject to some recent enhancements.

Group Naming Policies

For quite some time now we’ve been able to enforce a Naming Policy for Office 365 Groups. This extends to the implementation of blocked word lists for Group names… but it’s never been that straightforward. To date, configuration of these policies has been achieved using the PowerShell script below. Not complicated in itself, but unfriendly for monitoring and updating:

$BlockedWords = "<WordList>"

$PrefixSuffix = "<PrefixSuffixNaming>"

Connect-AzureAD

try
    {
        $template = Get-AzureADDirectorySettingTemplate | ? {$*.displayname -eq "group.unified"}
        $settingsCopy = $template.CreateDirectorySetting()
        New-AzureADDirectorySetting -DirectorySetting $settingsCopy
        $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
    }
catch
    {
        $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id       
    }

$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID

$SettingsCopy["PrefixSuffixNamingRequirement"] = $PrefixSuffix

$SettingsCopy["CustomBlockedWordsList"] = $BlockedWords

Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy

(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

Words defined in the $BlockedWords variable are prohibited from use, and the $PrefixSuffix is applied automatically. This latter object can be a static string, one of the following Azure AD attributes, or a combination of the two:

• Company
• CountryOrRegion
• Department
• Office
• StateOrProvince
• Title

So what’s changed?

Group Naming Policies are now available to configure in the Azure AD portal (albeit Preview)! 🙂 In the Groups node of the Azure Active Directory Portal we have a new Setting available: Naming Policy (Preview) containing two tabs; Blocked words, and Group naming policy:

These two new sections allow us to define the policy, and see at a glance what settings are configured. Infinitely more user friendly than PowerShell, and far, far easier to see what’s policies are being enforced on our users. We can also more easily view the prefixes being applied, and the supported attributes (a list I hope will grow in time, and extend to custom attributes):

The end user experience hasn’t changed. Naming Policies apply across the board in Azure AD and are invoked as soon as users type a new group name. Prefixes applied to Groups are shown in a preview, and blocked words are highlight to inform removal. For a summary of the experience across Office 365 apps, refer here.

From my perspective, this is a fantastic new addition. It simplifies the experience for administrators, and highlights the feature to those that possibly didn’t know it existed. It also delivers some much needed control, while retaining the freedom for users to consume services as they want to… win win!

The inclusion in the Azure AD portal might be a minor tweak, but it’s likely to make some incredibly happy. Thank you Azure AD team!

A brief post from me today to highlight something I stumbled across this week. I’ve not seen any formal communication from Microsoft on this change (although I’m sure it’s lurking somewhere), but it strikes me as a key new feature many will want to enable…

The process for registering Security Information is one which should be ultra secure. Control of this information allows the account password to be reset, or MFA challenges to be accepted. In theory it is; triggered as soon as it applies and subject to continual prompts (or blocked access) until complete. In practice it’s always unnerved me that any user, anywhere in the world can gain access and (theoretical) control of an account before registration takes place. Of course we can reset fraudulent or erroneous registrations, but minimising the chance is surely better. Now you can!

Security Information Registration Update

The control in question is a new setting within Azure AD Conditional Access. Under “Cloud apps or actions” we have a new “User Action” we can apply policy to: “Register security information (preview)”. Using this in tandem with conditions that specify locations or approved devices allows us to block registrations that don’t match criteria we set. For example those from users off of the corporate network, or those initiated from devices that are non-compliant.

Once enabled users who satisfy the username / password challenge but are required to enrol Security Information (or provide MFA) will receive a message. This states that whilst the sign-in was successful, the criteria for access wasn’t met ?

If you’re in a position where you can limit registration to trusted scenarios this is a great way of further securing your users. It’s not for everyone, but will accommodate a good proportion who onboard users locally. Go and have a play!

For those interested in other Azure AD recommendations, I discussed the 5 Things You Should Be Doing With Azure AD in a recent post. If I was writing it again this feature would get a mention. For those that haven’t read it already, why not spare 5 minutes to find out why I think many are missing out!

After much anticipation I finally had some proper time this last week to spend tinkering with Windows Virtual Desktop (WVD). For those unfamiliar, think of WVD as Remote Desktop Services (RDS) “as a service”. Microsoft manage and maintain common elements of the (shared) service infrastructure, removing the need for you to administer the underlying elements of RDS. It also supports a new “Enterprise for Virtual Desktops” edition of Windows 10 - providing multi-user, desktop operating system RDS for the first time.

I’ve been excited for the release since it was announced last year. As an organisation we ran sessions on WVD at Future Decoded, and I’ve been hinting at it’s potential for various use cases for the last 6 months or so. The challenge - as is always the case with “new” things - is whether it proves to be all it can be…

First Things First

Taking a step back, I’ve worked with Remote Desktop solutions of various sorts for a lot of years now. Traditional RDS (and Terminal Services back in the day!), Citrix XenApp, and VDI solutions like XenDesktop / Horizon View. Common to all of those is an increasing movement away from them in recent years, favouring more modern ways of working. Software as a Service adoption, advancements in MDM / MAM, and user expectations around how and when they should work have all played a part in shifting the focus from centralisation of data, to security of data beyond the LAN.

Some have speculated that Microsoft have missed the boat when it comes to Desktop as a Service, but I disagree…In spite of advancements, many organisations still have a need for a centrally administered user desktop experience. That’s unlikely to change in the short-medium term. For some this is driven by legacy application requirements, for others there are legitimate security constraints. Whatever the rationale, the introduction of a simple, low overhead desktop solution is a welcome addition - especially if it’s executed by Microsoft in the which we all hope it will be 🙂

Prerequisites

Before you get cracking with rolling out WVD, there are some things you need to consider:

Licensing: To date if you wanted to connect remotely to desktop operating systems you needed to subscribe to Windows 10 Virtual Desktop Access (VDA) licenses. Alternatively you needed to have purchased Windows 10 with Software Assurance. The approach to licensing WVD is considerably more flexible; extending eligible licenses to Windows 10 / Microsoft 365 subscription SKU’s.

Active Directory: Traditional Active Directory is a requirement for WVD - either full-blown AD in Azure, or Azure AD Domain Services. Native support for Azure AD isn’t available; unsurprising in many respects, but disappointing none the less for “Cloud First” organisations.

Profile Strategy: As you would in the “real world”, you need to plan a strategy for user profiles. This will be dictated in part by your choice of desktop approach (pooled, or personal). In any case, there’s a strong chance you’ll want to consider the use of FSLogix Profile Containers and Office 365 Containers. It’s been announced that both of these solutions will be included in the imminent FSLogix / Microsoft re-brand. Even more excitingly, these will be free for all subscribers of:

• Microsoft 365 E3 / A3
• Microsoft 365 E5 / A5
• Windows 10 Enterprise E3 / E5
• Windows 10 Education A3 / A5
• Remote Desktop Services (RDS) CAL (Purchased, or via CSP Subscription)
• Windows 10 VDA

Deployment

Microsoft have published a pretty comprehensive tutorial on how to get up and running on the WVD section of Microsoft Docs. For those interested, the high-level steps you need to take are as follows - interjected with a few of my own thoughts along the way.

Prepare the Infrastrucutre

• Consent to, and trigger the creation of the Server / Client App’s for Windows Virtual Desktop in Azure AD. You complete this at the WVD Consent Page and will need your Azure AD Tenant GUID. Don’t forget to repeat this for both the Server App and Client App registrations. On completion you should see two new Enterprise Applications registered in Azure AD: “Windows Virtual Desktop”, and “Windows Virtual Desktop Client”.
• Assign TenantCreator permissions on the new “Windows Virtual Desktop” Enterprise Application to the user who will establish the WVD tenant.
• Install and import the Windows Virtual Desktop PowerShell module on the machine(s) you will administer WVD from. Note that at the time I write this, much of the administration of WVD is PowerShell based. A new WVD management portal is in the works, but is unlikely to be released during the preview period.
• Create a WVD Tenant - this only needs to be done once using the following command(s):

# Connect to the WVD Service
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"

# Provision the Tenant
New-RdsTenant -Name <TenantName> -AadTenantId <DirectoryID> -AzureSubscriptionId <SubscriptionID>

• Create a Service Principal to use during the creation of the host pool. This step is optional, but recommended. Without defining a Service Principal, username / password credentials need to be used for Host Pool authentication to the WVD service. To create a Service Principal, ensure you have the Azure AD cmdlets installed and then run the following command(s):

# Define Variables:
$TenantGroupName = "Default Tenant Group"
$TenantName = <Tenant Name>
$aadContext = Connect-AzureAD
$svcPrincipal = New-AzureADApplication -AvailableToOtherTenants $true -DisplayName "Windows Virtual Desktop Service Principal"
$svcPrincipalCreds = New-AzureADApplicationPasswordCredential -ObjectId $svcPrincipal.ObjectId

# Connect to the WVD Service:
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"

# Define the Service Principal & Permissions:
New-RdsRoleAssignment -RoleDefinitionName "RDS Owner" -ApplicationId $svcPrincipal.AppId -TenantGroupName $TenantGroupName -TenantName $TenantName

$creds = New-Object System.Management.Automation.PSCredential($svcPrincipal.AppId, (ConvertTo-SecureString $svcPrincipalCreds.Value -AsPlainText -Force))

# Connect as the new SPO:
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com" -Credential $creds -ServicePrincipal -AadTenantId $aadContext.TenantId.Guid

#Verify Service Principal Access:
Get-RDSRoleAssignment -TenantGroupName $TenantGroupName -TenantName $TenantName

# Output the SPO Password & Application ID - Save these for Later Use
$svcPrincipalCreds.Value
$svcPrincipal.AppId

Create the Desktop Environment

• Deploy a Host Pool using the “Windows Virtual Desktop - Provision a host pool” entry from the Azure Marketplace. Most of the steps in this wizard will be self-explanatory and unique to your environment.
• When prompted for the usage profile and number of users, the template will make an assessment on the best instance type and volume of VM’s required. This can be tailored, and also influenced by the load balancing method chosen (Breadth First, or Depth First). I won’t be going into the detail of these aspects in this post, but know that there is significant capability within WVD to automate the scale up, scale down, and placement of users based on various performance metrics.
• For the purpose of testing I elected to use the gallery Windows 10 image. You are able to prepare and register your own if you prefer - additional steps apply in this case. Again, I won’t be covering these elements in this post, but I’m happy to address questions in the comments and may focus a future post on this aspect of WVD.
• On the “Authenticate to Windows Virtual Desktop” section of the Host Pool creation wizard, choose whether the username / password, or Service Principal authentication method is to be used and populate the relevant fields. If you are enforcing MFA on all user accounts, a service principal is required.
• On completion, you will be able to confirm the successful creation of your host pool through the presence of Virtual Machines in the Resource Group you defined, and via the creation of a Host Pool object. To view details, run the following command from a PowerShell session connected to your WVD Tenant:

Get-RDSHostPool -TenantName <tenantname>

Connect to the Service

At a basic level, your WVD Deployment is complete. You should be able to connect to your desktop(s) with the accounts specified in the Host Pool creation wizard. This can be done with the Web Client (accessible here), or by installing the preview version of the Remote Desktop Client, available here.

To add or remove users to the Virtual Desktop, use the following commands:

# Connect to the WVD Service:
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"

# Assigning User(s) to the Published Desktop:
Add-RdsAppGroupUser <Tenant Name> <Host Pool Name> "Desktop Application Group" -UserPrincipalName user@domain.com

# Removing User(s) from the Published Desktop:
Remove-RdsAppGroupUser <Tenant Name> <Host Pool Name> "Desktop Application Group" -UserPrincipalName user@domain.com

It’s not possible to use Active Directory Groups for the assignment of permissions (at the moment).

Application Publishing

You’ll notice from the above screenshot that it’s also possible to publish applications to users, not just full desktops (RemoteApp). There’s an important thing to highlight on this front when it comes to WVD. Before I explain, I’ll provide a brief overview of the terminology used to assist:

The basic elements of WVD are:

• Host Pools: Containers that house Virtual Machines to deliver desktop / application resources, and Application Groups. Load Balancing attributes and session limits are defined at the Host Pool level.
• Application Groups: Determine the type, and detail of resources published to assigned users. They have a Resource Type designation of either Desktop, or RemoteApp, but not both.

“Now what’s that important thing”, I hear you cry? Well…it’s this. Users need to be assigned to the Application Groups that host the resources we want to give them access to. There will be scenarios where you want to provide flexibility around the user experience - enabling the choice of accessing either desktops or applications. At the time of writing, a user can only be assigned to one Application Group in any single Host Group. To accommodate this flexibility then, you need multiple Host Groups to support a mix of RemoteApp and Desktop assignments for users.

This isn’t a show stopper by any stretch. It does require you to double up on session host infrastructure though, and makes the overall experience that little bit more complex.

RemoteApp Configuration

To publish applications to those users who will also be accessing desktops, we first need to create a second Host Pool. If this doesn’t apply, then the below steps can be run on same pool you will be using for Desktop access.

Run the following commands to create a new Application Group, and to assign users:

# Create the Application Group:
New-RdsAppGroup <Tenant Name> <Host Pool Name> <Application Group Name> -ResourceType "RemoteApp"

# Verify Creation:
Get-RDSAppGroup <Tenant Name> <Host Pool Name> <Application Group Name>

# Assign User(s) to the Application Group:
Add-RdsAppGroupUser <Tenant Name> <Host Pool Name> <Application Group Name> -UserPrincipalName user@domain.com

# Verify User Assignment:
Get-RdsAppGroupUser <Tenant Name> <Host Pool Name> <Application Group Name>

Once the Application Group is created, you need to define the individual applications for publishing. Run the following to retrieve the available application aliases from the Session Host Start Menu. We use these to define the RemoteApp objects within the Application Group:

# List Available Applications:
Get-RdsStartMenuApp <Tenant Name> <Host Pool Name> <Application Group Name> | Select FriendlyName,AppAlias

# Define RemoteApp Applications (Examples):
New-RdsRemoteApp  <Tenant Name> <Host Pool Name> <Application Group Name> -Name "Word" -AppAlias word
New-RdsRemoteApp  <Tenant Name> <Host Pool Name> <Application Group Name> -Name "Excel" -AppAlias excel
New-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name "Paint" -AppAlias paint
New-RdsRemoteApp <Tenant Name> <Host Pool Name> <Application Group Name> -Name "Google Chrome" -AppAlias googlechrome

# Verify RemoteApp Creation
Get-RdsRemoteApp  <Tenant Name> <Host Pool Name> <Application Group Name>

Summary

That’s a wrap for this post 🙂

There’s a whole lot more I could dive into on Windows Virtual Desktop. Some things I’ve referenced in this post, others may crop up as you start to spend time with the product. Needless to say though, this post is plenty long enough already, and if you’ve made it this far you’ve done well 🙂

I plan to put some other more specific posts together on some of the more involved functionality of WVD. Some PowerShell tips and tricks covering deployment and administration, in addition to some deep-dives on specific functional areas like Profile Management and Scaling. Irrespective, I’d welcome comments and feedback from anyone else who’s dabbled with it to date - feel free to get in touch.

This is a slightly left-field post in comparison to other recent entries, but hopefully useful to others preparing for Microsoft’s MS-500 Security Administration Exam. For those not in the know, MS-500 is the exam in the “MS” series focussed on the security centric features of the (Microsoft) 365 suite. A full list of skills measured is detailed on the exam page, but suffice to say there’s a plethora of features covered including Identity, ATP (Defender, Azure, and Office 365), Azure Information Protection, Intune, [Cloud App Security] (https://www.microsoft.com/en-gb/cloud-platform/cloud-app-security), and the various approaches available with respect to ensuring compliance with various regulatory and legislative frameworks…

It’s a bit of a beast.

This wasn’t an exam that was on my radar until a week or so ago. I was inspired (or arguably egged on!) by @Microsoft365Pro on Twitter who had recently completed the exam. Given my interests and focus (which this blog is becoming something of a testament to), it seemed like a natural exam to slot into my roadmap - expedited and made slightly easier by the fact that I had a free exam voucher burning a hole in my pocket following the recent AZ-100 / AZ-101 retirement debacle ?

I was home slightly earlier than I expected to be today and thought I’d see what exam slots were available over the next week or so…as luck (or not!) would have it, there was an immediate slot available. I bit the bullet, and here we are a few hours later with my initial feedback and thoughts (having passed, you’ll be pleased to hear!)…

So how was it, and what are the key things you need to know to help you prepare for the MS-500 Exam?

If you’re here for the inside scoop / gossip in the form of exam content, you’ve come to the wrong place. That’s very much not my style, and I’d suggest you [have a read of this link(https://www.microsoft.com/en-us/learning/certification-exam-policies.aspx) in place. I will give you some pointers based on my experience though - and hopefully send you in the direction of some useful content that will help you on your way…

Know your content. In case it wasn’t obvious, you absolutely need to have real world experience on the topics covered in this exam. The questions assume you know your way around the security tools available in the M365 suite, know how to find and configure settings, and know where to go to troubleshoot and monitor the various metrics available.

Have access to a tenant with M365 E5 Licensing. Like most Microsoft exams, the questions assume the presence of top-tier licensing, which introduces a whole range of additional functionality that you may not have had much exposure to. Expect questions on Azure AD P2 functionality like Access Reviews and Privileged Identity Management, have experience of Cloud App Security, and understand features like automatic labelling in Azure Information Protection. If you don’t have access to a live tenant, then sign up to one of the Microsoft Demos at demos.microsoft.com.

Be comfortable addressing scenario based questions. I’m not sure how much I can say publicly about the structure of the exam, but being able to apply Security tools within the M365 stack to real world scenarios and challenges is essential. Expect case studies, and expect questions that force you to apply logic to situations to work out the answer (as opposed to a simple right / wrong response).

Read the literature. Microsoft Docs is a fantastic resource for getting to grips with features, caveats, and configuration detail relating of some of the more niche elements of the services in scope . If you don’t have the time or inclination to trawl through yourself, then refer to one of the fantastic study guides (as a part of your wider learning!) that @Microsoft365Pro and @intunedin have put together - both call out the specific articles that relate to each of the exam objectives:

• Microsoft 365: Security Administration (MS-500) Exam Prep Guide (@Microsft365Pro)
• Preparing for the MS-500 Microsoft 365 Security Administration Exam (@intunedin)

Take some of the foundational MS Exams first. If you haven’t already, I’d encourage you to look at taking MS-100 and MS-101 before you sit this one. There’s some natural overlap of content, but MS-500 builds quite significantly on the security concepts that are touched on within these two exams. More Conditional Access, more Cloud App Security, and more Intune. You have been warned!

In Summary…

This was an enjoyable exam for me. I didn’t do a huge amount of preparation, but I do deal and enjoy working with with the technologies covered on a near daily basis. It builds nicely on some of the more entry level M365 based exams, and felt like a really well structured (albeit broad) exam that pulled together the (quite fantastic) security and compliance tools available from Microsoft. Is it one of those staple exams that everyone should do? Likely not, but if you have more than a passing interest in security the MS-500 Exam is one I’d highly recommend…

Happy learning, and good luck!

I have a lot of meetings where identity (the Azure AD variety…! :)) is a central theme. These usually start out as broader conversations on Office 365 or Cloud Security in general, but more and more frequently Azure AD is front and centre. Increasingly it’s the only topic of conversation from beginning to end…

Why? There are a host of technically exciting features - some have a basic understanding of what those are and simply want to know more. More often than not though, there are those lightbulb moments during conversation where the significance and value that Azure AD can bring becomes apparent.

So, where do you start with Azure AD? Why should you be looking at it as more than just the “authentication back end” to Office 365? I thought I’d take a moment to highlight a handful of the things I think are key to it’s success right now and which are worthy of consideration for those who want to understand how it can be used more extensively today (note: some of these features assume Azure AD Premium licensing)…

1. Authenticating Users in the Cloud

This is a key factor in the ability to drive maximum value from all that Azure AD can offer, and represents a significant shift in thinking when compared to best practices of just a few years ago. Many IT Professionals assume (with good justification in a lot of cases) that Active Directory should be king in its role as “gatekeeper” of corporate resources - even those homed in the Cloud. This has driven the design of hybrid identity solutions that incorporate technologies like ADFS or Pass-Through Authentication (PTA) in tandem with Azure AD Connect. Recent improvements to the capabilities of Azure AD, the significant security benefits that come from authenticating directly in the Cloud, and the increased desire to reduce the dependency on on-premises infrastructure have all played a part in changing this view in the last year or so though - to the extent where you can be hard pushed to justify any solution now that delegates authentication (and as a result a dependency) to the local AD.

Microsoft have published some excellent guidance on how to choose the correct authentication model for your organisation, together with some of the rationale behind the change in guidance and best practices. This can be found at aka.ms/auth-options, and includes the decision tree below which covers the available options for handling authentication:

Without wanting to spoil the surprise (and in case it isn’t already evident!), there are very few standard scenarios where it doesn’t make sense to do away with ADFS / PTA in favour of Password Hash Synchronisation (PHS) and Seamless Single Sign-On (SSSO). This enables the adoption of a whole range of advanced security tools and controls; Identity Protection, native Conditional Access, the ability to take advantage of the significant Threat Intelligence Microsoft has access to through it’s processing of millions of authentication transactions each day etc… It also reduces your risk profile - removing any dependency on your on-premises Active Directory for authentication altogether. Win win 🙂

2. Integrating Applications

Azure AD has been assumed by some as being “AD in the Cloud for Office 365”. Whilst there are a host of things wrong with that statement, the sentiment also does a huge disservice to the ability of Azure AD to become the primary authentication provider for your organisation; covering a huge array of applications ranging from third-party Software as a Service applications like SAP and Salesforce, to published (on-premises) line of business applications and other Microsoft Cloud services.

The real advantage of embracing Azure AD in this way is the ability to centralise authentication - aiding the administrative overhead of dealing with starters, leavers, and general access management - and also to further secure SaaS (and other) applications through some of the advanced security controls I mentioned above, such as Conditional Access. All of this happens in a way which is friendly to the user - centralising the applications available to them using the “My Apps” portal, and taking advantage of Single Sign-On capabilities built into Azure AD to minimise the need to authenticate against each individual application.

From a governance perspective, integrating applications with Azure AD provides much needed visibility and control over third party services that may be in use - reducing the likelihood and impact of “shadow IT”, whilst simplifying the user experience where services are fully integrated through automatic user provisioning and SSO.

3. Using Privileged Identity Management (PIM)

Privileged Identity Management (PIM) is one of the hidden gems within Azure AD - arguably “hidden” due to its inclusion in only the P2 version of Azure AD Premium, but a fantastic security addition to any organisation serious about adopting the principle of least-privilege.

The premise of PIM is that access to (and exposure of) high privilege accounts should be minimised wherever possible. In practice many organisations aim to do this by leveraging dedicated administration accounts with high levels of associated security, but the fact remains that these accounts are viable targets for as long as they hold administrative rights, and also introduce internal risk through misuse (deliberate or accidental).

PIM mitigates these risks by changing the model of applying administrative permissions from one of assignment, to eligibility. In place of high numbers of permanent administrators, users can be made eligible for administrative roles - requesting and receiving access on a “just in time” basis as is needed, and subject to automatic revocation after a defined period of time.

The elevation process is user initiated from the Azure portal and can be subject to administrator approval - ensuring that rights are assigned only when needed, with justification, and only for as long as is needed. Activities are recorded and can be reviewed using the Audit History view at any time. PIM is a hugely powerful capability and justifies the cost of P2 licensing in its own right (in my opinion 🙂)

4. Configuring Azure Password Protection

I dedicated a previous entry to an overview of the Azure Password Protection (APP) feature of Azure AD. You can read about it in some detail in that post if you wish, but for the uninitiated APP extends traditional password complexity requirements (in both Azure AD and Hybrid scenarios) by allowing you to determine specific words or phrases that should be banned from use in user passwords. This customised list is supplemented with the “global banned password list” - a managed database of frequently used and compromised passwords based on behaviour and attack detections across the Microsoft Cloud.

APP requires Azure AD P1 or P2 licensing in order that you can benefit fully from its capabilities, but is a fantastic way of improving the security baseline of your organisation through policing of one of the few things you can’t easily “control” as administrators. I’d always advocate the use of other controls in the authentication process to bolster security - MFA, Conditional Access etc. - but the fact remains that right now passwords are an intrinsic part of the user experience and will be for at least the short-medium term future.

5. Using Azure AD B2B Collaboration

Azure AD B2B (business-to-business) is another one of those golden, somewhat hidden (or at least not widely talked about) collaboration features, allowing you to share applications bound to your own Azure AD - such as those referred to in the “Integrating Applications” section above - with users homed in other organisations.

We’ve gotten used - over the years - to assuming that in order to provide access to resources in environments we manage, we need to create and manage local identities for those guest users. This is problematic on a couple of fronts . For one, managing users external to the organisation is fraught with challenges around licensing, security, governance, and compliance. It also leads to a poor user experience for those assigned access; one service = one credential, another service = another credential… far from elegant. Imagine a world where your one corporate identity (ideally your Azure AD account) was your token into every corporate application you needed to do your job or access the data you need. This is essentially what B2B enables, albeit there’s flexibility that doesn’t mandate the invited account to be Azure AD aligned.

Is it perfect? No. The process associated with onboarding and managing guest accounts at scale (as is sometimes needed) is clunky, but it is a significant step forward from the days of creating remote user accounts in your own domain. This limitation in particular is due an overhaul at some point this year (hopefully!) through the introduction of “Tenant Friending” - something I’ll post more about when details allow.

So there you have it… 5 quick(ish!) things you can consider using today to dramatically enhance the service you provide to end users, improve your security, and get you well on the way to adopting Azure AD in a way which you possibly didn’t imagine you could (or would). The future is bright when it comes to Azure AD with significant investment being poured into the platform and new - quite amazing - features being introduced month on month. Getting under the bonnet of what’s possible when it comes to Cloud Identity is worthwhile investment - I have absolutely no doubt there will be more and more emphasis placed on Azure AD as we step through 2019 and beyond.

Last week saw Microsoft announce General Availability for Azure Password Protection (APP) following a fairly lengthy spell in preview. This is an exciting feature release; bringing an end to the days of bespoke password filter DLL’s and adding much needed security, simplicity, and flexibility to password standards - backed by the power and intelligence of the Cloud.

What is it, and why should you use it?

Azure Password Protection extends the regular password complexity configuration of Azure AD, enhancing protection through the policing of user passwords and enforcement against a mix of automated and custom policies. It supports two main functions:

Restricting the use of common, or poor passwords through validation against an administrator defined custom password list and the “global banned password list”. This latter “thing” is a dynamically generated and maintained database - managed by the Azure AD Identity Protection team - comprising commonly used and frequently compromised or breached passwords based on behaviour and attack detections across the Microsoft Cloud.

Extending the protection afforded by Azure AD to on-premises environments, enabling customers to benefit from the security advantages introduced via APP in traditional Domain Services environments. This is achieved through the deployment of a combination of Domain Controller Agents (whose role it is to process password validation requests), and the Password Protection Proxy service (which supports communication with Azure AD - relaying the APP policy to each DC Agent when requested) - depicted (ever so helpfully) in the below diagram from the Microsoft APP documentation:

How does it work?

The approach taken by Microsoft in enforcing banned passwords is a really interesting one… You might expect the service to apply a fairly crude yes / no approach when assessing user selected passwords, but there’s actually a lot more that goes into the evaluation process than you’d imagine. The steps are explained in detail in the Microsoft documentation, but by way of an overview, consist of the following:

Normalisation: This stage focusses on performing common character substitution (0>o, $>s, 3>e etc.) and removing upper case characters to support the matching of user selected passwords against entries in the global or custom blocklists. This (in Microsoft’s words) “allows a small set of banned passwords to be applied to a much larger set of potentially weak passwords”.

Fuzzy Matching: This is applied to the normalised password, ensuring that any proposed password is removed by more than one “edit degree” from a banned password. This step also verifies that the users first and last names, along with the Azure AD tenant name are not present in the proposed password (post normialisation and fuzzy matching).

Score Calculation: This final step applies a score to the output of the first two steps. A single point is assigned to each banned password reference, along with a point for each additional unique character. If the resulting score exceeds 5 points (and aligns with any other policy requirements - e.g. password length), the password is accepted. If not, the password is rejected on the basis that it fails to match the required level of complexity.

Deployment & Next Steps

First things first, you should be aware that to benefit fully from APP you need to have Azure AD Premium licenses. For Cloud-only Azure AD accounts (i.e. those provisioned directly as opposed to those synchronised via AD Connect) you can evaluate the use of passwords from Microsoft’s global list for free, but that aside you’ll need an Azure AD P1 or P2 licenses.

Assuming you’re correctly licensed, all of the settings you’ll need are located in the Azure AD portal under Authentication Methods > Password Protection. From here you can configure Smart Lockout thresholds, your custom banned password list, and integration with on-premises Domain Controllers if desired. Whilst I’m not covering the steps associated with the latter element in this post, those that are should refer to the to the On-Premises Integration Deployment Guide - paying particular attention to the pre-requisites. I’d also suggest reviewing the steps for High Availability. Absolute uptime of the proxy servers isn’t necessary, but an understanding of the interaction between DC Agents and the APP service is likely to serve you well…

…it really is as simple as those few settings 🙂

For me, this is one of those “no brainer” features that all organisations should consider where licensing permits. There will be many who want to consider integrating with on-premises domains - leveraging the additional control that this provides in helping to secure the use of poor passwords, but equally there’s huge value in being able to benefit from the intelligence that Microsoft bring to the table via the Identity Protection team.

Take a look, and feel free to respond with any comments or experiences you have. I’ll likely go into more depth on deployment and on-premises integration in a future post. In the meantime, happy playing 🙂

This is a slightly left-field post on the back of some testing / tinkering I’ve been involved in over the last week or so. It’s not quite the post I had planned, but since I’ve not quite achieved what I set out to (yet, more on that in a future post) and this was a useful by-product along the way, it seemed silly to waste the opportunity of writing up some findings that will hopefully prove useful to someone down the line…

Fortinet’s FortiClient based SSL-VPN implementation is one of the best and simplest out there and has been a fairly staple feature on pretty much every FortiGate I’ve deployed since 2009 or so. One thing I haven’t ever explored though is the use of certificates as part of the authentication process - deferring instead to the more traditional approach of using RADIUS for Active Directory integration, or third-party MFA support where there’s more than a passing requirement.

Client VPN’s seems to have had a bit of a resurgence for a number of the organisations I work with in recent months, but given our Azure focus and the limitations associated with native Microsoft options in the cloud (lack of RRAS support, administrative complexity of P2S VPN’s etc.) we’ve found ourselves exploring and building solutions based on more traditional appliance based VPN solutions in Azure - Fortinet, Cisco, Palo Alto etc. A question I’ve been exploring is “how can we make these better / slicker / more secure?”.

The ideal world for me is the integration of Microsoft Always On VPN with a supported third-party appliance in Azure given the (theoretical) ability to do just that. One of the key advantages of Always On is it’s support for non-Microsoft IKEv2 / SSTP / L2TP compatible VPN appliances - which can (again, in theory) mitigate some of the challenges associated with the aforementioned Azure limitations. The reality, as I’ve experienced this week during testing, is that this isn’t as straightforward as you would hope when it comes to Azure. Is it possible? I absolutely hope so. How do you do it? Well… that’s the “future post” I’ve alluded to above - all being well 🙂

Back to certs and SSL-VPN in FortiClient… the inclusion of certificates in the user authentication process brings with it some advantages:

MFA: It introduces a level of multi-factor authentication that’s transparent to the user. This happens via background presentation of a user certificate containing a subject name that’s aligned to the authenticating user.

Device Level Security: Through the requirement for a user certificate to be present on the device, access is limited to trusted devices that fall within the governance and scope of corporate / enterprise IT.

Revocation: Linked with the above, certificates can be revoked / reissued at any time, ensuring the integrity of all connections to the corporate network.

Configuring Certificate Authentication for FortiClient

The process for enabling Certificate Authentication for FortiClient is actually relatively straightforward and involves just a few minor tweaks to the firewall configuration and regular SSL-VPN profile. Of course this assumes that you have a working PKI infrastructure in place, with the ability to issue user certificates to the devices of users who need to connect.

Step 1: Download the root certificate of the CA that will be responsible for issuing client certificates (along with any intermediary / issuing CA’s from your Certificate Authority) and upload as an External CA Certificate within the System > Certificates section of your FortiGate.

Step 2: Toggle the “Require Client Certificate” to “on” within VPN > SSL-VPN Settings. Note that if you have working clients they will be unable to access until they are defined as PKI users once this is enabled.

Step 3: Add users within User & Device > PKI, populating the “subject” field with the subject name from the certificate they will be using for authentication, and setting the “CA” field to reflect the External CA Certificate uploaded within Step 1. If the “PKI” section is not visible, create your first user via the CLI using the following commands as a template. Once the first user has been defined, the relevant views within FortiOS will be available:

config user peer
  edit kelvin-ca
    set ca CA*Cert*1
    set subject kelvin
  end

Once the user has been added, toggle the “Two-factor authentication” setting to on and specify the password you want to assign to the user for SSL-VPN access.

Step 4: Within FortiClient, modify your VPN connection to include presentation of the relevant Client Certificate in place of “none”… and you’re done!

Certificate Authentication may not be for everyone, and it’s fair to say that there are other mechanisms for limiting device access and enhancing the security of VPN connections, but I was pleasantly surprised at just how straightforward the configuration of certificate auth was for FortiGate SSL-VPN.

Again, it’s not the blog I’d intended to post… but I hope this proves useful for some 🙂 Keep your eyes peeled for something soon that will hopefully blow this out of the water as far as simplicity, security, and ease of remote access is concerned… watch this space!

Every now and again I post something on Twitter that seems to resonate and prompt more of a reaction than I expect… a recent example - and ironically the reason that I decided to bite the bullet with this blog - was the tweet below regarding the (now not so) new release of Azure Sentinel; Microsoft’s answer to SIEM for the modern Enterprise:

Why does this excite me so much? I’ve spent a good chunk of my career in security-centric roles for one reason or another. The first “proper” IT role I had was with an Aerospace & Defence organisation who (naturally) placed a significant emphasis on security. My progress at that company culminated in a role as a security lead for a major integration project, which in turn played a significant part in allowing me to develop a range of skills that have held me in good stead for the last 10+ years. More recently I held a position as a Security Product Manager for a large MSP, and right now an element of my role involves ensuring we remain technically compliant with our obligations under Cyber Essentials and ISO 27001…

In short, I seem to gravitate towards the murky, yet fascinating world of IT security and announcements like this get me far more excited than perhaps they should do…!

The Problem…

The problem with “IT security”, as I’ve come to learn over the years, is that it’s shrouded in so much complexity and jargon that it’s seen as a burden to most organisations - particularly those that lack the in-house resource to be able to give it the focus it needs. Most understand the concept and need for a firewall, for decent antivirus, perhaps even going as far as adopting MDM / MAM solutions or cloud filtering services, but few proactively monitor or manage the activity in their environment to the extent where they can detect not just clear-cut attacks or violations, but suspicious or preparatory activity by “bad actors”. The calm before the storm!

Doing security “properly” is typically the domain of the enterprise - specialist tool-sets and dedicated, expensive expertise to monitor and decipher all of the underlying (often hidden) “noise” that provides the real view of what’s going on. One of the biggest contributions to this analysis usually comes in the form of SIEM (Security Information and Event Management) software which collates and analyses signals from across the infrastructure and network, providing insights based on predefined or automated logic. The biggest challenge with these tools is that by nature they surface noise. Lots of it.

The Reality…

In spite of best intentions and significant progress in recent years, false-positives are part of the daily life of those that work in SecOps. Minimising these requires customisation and tuning, training systems to understand “normal”, and a constant battle to ensure legitimate concerns aren’t buried. I’ve had the “joy” (yes, that’s serious and sarcastic!) of working with some of the leading tools in this space and not one has “just worked” in the way that many vendors tell you they will. The net result is time and effort - at great cost - for solutions that often end up being a significant drain on IT departments, or worse still, ignored until it’s too late.

This shouldn’t really be a surprise. Security is complex, and as a result is costly. But should it be? Should smaller organisations find themselves exposed to risks that could be avoided because they don’t have deep pockets? Should organisations be forced into hiring security experts at great cost? (sorry, security friends!). Possibly not for much longer.

A Solution?

Enter Azure Sentinel. I saw the announcement on launch day and I have to be honest - I wasn’t overly hopeful. Microsoft have made significant strides into the Security space in the last couple of years, but a proper contender for Enterprise SIEM? I’d heard rumours of a product in the works and expected something that would better accommodate Azure workloads, integrate with Platform Services, and potentially represent a step into the “as a Service” world . I didn’t expect it to be all of those things and then some. I especially didn’t expect it to trigger a change in my thinking towards SIEM through it’s addressing of many of the challenges that I associate with products of old (as above).

So what’s different? For one, it deploys in minutes (no exaggeration). I was able to stand up an Azure Sentinel instance, integrate it with half a dozen or so (Microsoft) cloud services, and started to see data flowing into my workspace within about 15 minutes. It also takes advantage of the platform it sits on, leveraging the significant scale of Azure to assist with event correlation, and Machine Learning to identify suspicious patterns or threats in the underlying data. You can augment this with your own alert rules (or those available in the Sentinel GitHub repository), and will be able to automate response actions within the alert definitions - triggering playbooks based on Logic Apps that can notify, or remediate threats based on predefined flows of actions.

I’ve been playing with Azure Sentinel for the last 3 weeks or so, getting to grips with its capabilities and it’s limitations. Is it perfect? No. In part this is down to limitations associated with the preview (some of the headline functionality such as automated playbook execution, and visual context maps aren’t yet enabled). Is it good enough to rock the boats of some of the more established vendors though? Absolutely. What’s exciting for me is the potential for (all) organisations to be able to benefit from some of the insights that have only been available to the select few. This is about “proper” security for the masses - a very real step forward that demonstrates the power that the Cloud can bring to organisations of all shapes and sizes.

In Summary

There’s a whole lot more I could cover… not least some more technical content showing the configuration and administration experience associated with Sentinel. I intend to cover both in the coming weeks, but needless to say, if you haven’t taken a look at Sentinel just yet you really should. I’m certainly excited to share more on it with you in future posts!

I’m not a fan of these types of posts… “Hi, this is me” seems super self-indulgent, but equally it doesn’t feel right to launch straight into content without setting context or expectation of what it is that I, and this blog, are about. So, “Hi, this is me”, I guess…

I’m a little late to the party. I could have, and should have started blogging when it first crossed my mind 5 or 6 years ago. As I suspect is the case with most though, the thought and motivation of getting going with it passed, and here we are several years down the line with that recurring “should I do it” thought coming back to mind. So here goes.

The ambition is simple. I want to document the thoughts and insights that I have as I go about my work. I’m fortunate to be in a position where I’m exposed to all sorts of new and exciting technology, including the opportunity to gain early insight and perspective on many of the developments taking place in and around the Microsoft Cloud. It’s a hugely exciting time, and a tipping point in our industry in my opinion - as feeling and perception on where, how, and why “the Cloud” makes sense starts to take a hold.

My background is similar to many in this space - years of experience (I can say that now I’ve been around for a while!) working with traditional on-premises infrastructure and systems, some “dabbling” with Cloud as it began to mature, to a position now where I work almost exclusively on Cloud based solutions for organisations of all shapes and sizes. I work as a Solutions Architect for a leading Microsoft partner; consulting on, designing, and positioning solutions that look to utilise (mainly Microsoft) based infrastructure and services. I’m not interested in being a part of the latest bandwagon, I want to be seen as someone who influences and effects positive change through awareness and deployment of some of the truly staggering capabilities that exist today.

I have a particular interest in Security. That will be evident throughout my posts I’m sure, but that’s not to say it will be a sole focus by any stretch of the imagination… Expect to see all manner of things featured and discussed from the user and endpoint, to back end infrastructure and services, and everything in between. My world revolves around Modern Workplace and Azure at the moment; so expect a reasonable portion of Office 365, Intune, and Azure AD, sprinkled with some IaaS and PaaS along the way!

I have a couple of blog posts in the making which I’ll be kicking off with soon… that aside I look forward to seeing what comes of this. No promises on regularity, but hopefully this proves to be as useful a resource to others as some of the blogs I follow have been to me.

Happy reading, by all means connect with me on Twitter or LinkedIn if you want to get in touch! That aside, I hope you enjoy this the blog!