roeleverink.nl

PowerShell Function app behind Azure AD authentication

2019-11-27T00:00:00+00:00

Every year, me and a couple of cousins of mine pick a day, and we game all day. Usually it’s an old game that everybody can play. Like Command & Conquer: Generals.
Back in the days we all came together and linked our PC’s with a switch, and we were good to go. But these days we’re grown up and living miles apart, so we usually link our PC’s over the internet. With an old game like that, connecting over the internet doesn’t work that well or isn’t supported at all, it needs a LAN. So I build an pfsense server in Azure that supports Layer 2 broadcast messages over the VPN. This all works really well.

To reduce my Azure spending I have an auto shutdown schedule configured. It shuts down my VM at 23:30, and it stays that way until turned on.
Sometimes my cousins want to game while I have to work, or have other stuff to do, and I don’t have time to turn on my Azure VM, and of course, I don’t want to give them access to my subscription either.

There is a solution for my usecase:
Azure Functions

Azure Functions for PowerShell core is now General Available, so its fully supported. And it gives me the opportunity to secure it behind Azure authentication.

1. Setup

For this we will need 2 functions

One function will be the main website, it should also show the status of my VM, it will contain a button that will trigger my second function
My second function will start my VM. It should also give some status back.

Both functions can use the same Function App. They will both have to be secured with Azure AD authentication, so not everyone can start my VM.

With this setup done, lets start building

2. Creating the Function App

We can start by creating a resource group to hold our functions.

I call my resource group: RG_WEU_SelfServiceFunctions, as it’s located in West Europe.

After that we can go to: +Create a Resource -> Search for: Function App -> Create

Select a subscription. And select your resource group that you just made. Give your function app a name, it should be globally unique
For Runtime stack choose PowerShell Core

On the next page you can create a new storage account, or choose an existing one.
For the plan I chose Consumption, depending on your usecase you can also choose another plan.

As I don’t need any monitoring I turn application insights off. This is only for my personal use, so I don’t need any monitoring.

Then on the Review + Create tab. Choose Create

3. Creating a Managed Identity

To determine the status I can use the Az PowerShell module, the Az module is supported right out of the box in Azure Functions, so I don’t have to install it first. But I do need an account to authenticate to my subscription.
For this we can use a managed identity.

The managed identity is created on the Function App level, so it’s for all our functions in our Function App. Go to the function app -> Platform features -> Identity

Change the status to On and then click Save

Our Function App now has a managed identity, but it doesn’t have any rights in our subscription. For this I assign rights on just the resource group, but depending on your function you can also assign rights on the subscription level.

The managed identity has the same name as your function app. Select it, and click Save

4. Creating the first function

Once your Function App is ready, and you have your managed identity, you can create a function with the quickstart by clicking on the + sign next to functions.

The downside of the quickstart is that it will give your function a standard name. If you want to name your function yourself, click on Functions and then + New function

As my first function will be a website, the trigger is an HTTP trigger, it will be a simple GET request like any website, so click HTTP Trigger
After that you can give your function a name, and authorization level. I chose Anonymous, as I will add Azure AD authentication later.

We get thrown into a webeditor to edit our function. As I want to show a webpage, I have to build some HTML code, and insert some status about my VM. As we created a managed identity we can just use Az commandlets, and it will use the managed identity to authenticate. For the code, it can be found on my GitHub repo.

There’s only one more thing to do. Currently my function supports both the GET and POST method. We can disable the POST method.
This is done on the Integrate section. Deselect POST, and click Save

To test your function, you can go to the webpage. It’s in the form of:

https://<functionApp-name>.azurewebsites.net/api/<function-name>

You can also find it in the interface on the following location

5. Creating the second function

As you might have noticed, in our first function we call the second function with a POST method. It doesn’t really contain any data, but you could build it like that if you would want to (like selecting which VM to start for example).

The procedure for the second function is the same as the first function. There are a few exceptions:

We name it vmstarter
Allowed method is now POST, so we have to uncheck GET under Integrate

That’s it. It uses the same managed identity as our first function, as they both are using the same function app.

For the PowerShell code, you can use and edit the code on my GitHub repo.

Now it’s time to test the function and see if the VM will start!

6. Add AzureAD authentication

As I don’t want my functions exposed to the internet I can add Azure AD authentication. This can be enabled on the Function App level. Go to your function app, and click Platform features -> Authentication / Authorization

Turn On App Service Authentication
In the dropdown menu, select Log in with Azure Active Directory
This will deny any unauthenticated request to my functionapp. We will have to configure Azure AD, so click on Azure Active Directory

For Management mode, click Express, and click OK
This will create an app registration in Azure AD, called selfservicevm

Click Save again.

This will enable Azure AD authentication. If you login to the function app again, you will be triggered to login. Because our app wants to read the profile, everyone has to give consent, or you can give consent on behalf of your organization with a global admin account.

Now all users can login to your function app!

In my case, I can invite my cousins as guest users to my Azure AD, so they can also use this with their own Microsoft accounts.

7. Group or user based access

If you want to control access to your application based on group membership or to single users, that is also possible. The selfservice app can be found under Enterprise Application. In the properties section User assignment required is now set to No. This means everyone in our tenant has access. This can be set to Yes.

After that go to Users & Groups and select the users or groups that are allowed to access the application.

You can edit this to your own needs of course. You can let groups of users like your developers select VM’s to start / stop / reboot. Or you can even do complete ARM template deployments from inside your functions.

Deploy a Shared Image Gallery image to Windows Virtual Desktop

2019-11-15T00:00:00+00:00

In my previous post I showed how to create an image with Azure Image Builder. In that post we created a managed image, from which we could deploy a VM, or use in our Windows Virtual Desktop - Hostpool deployment.

Another thing we can do with Azure Image Builder, is push our image to a Shared Image Gallery.
Let’s first dig into what a Shared Image Gallery is. It is a Gallery in which you can define Image Definitions. You can for example have a Definition for each golden image that you use for a hostpool.
You can have an image definition for your helpdesk staff, with callcenter software and an incident management system, and another image definition for your system administrators with management tools deployed for example.

And each of your image definitions can have multiple versions. So you can have versioning for your golden images! With versioning a rollback to a previous image version will be easy!

Now, the downside is you can’t choose a Shared Image Gallery image version when deploying Windows Virtual Desktop. So, we have to create that option ourself.

But first we have to create a Shared Image Gallery, and enable Azure Image Builder to distribute to it.
Afterwards Azure Image Builder needs rights on the Shared Image Gallery to write to it.
Then we can distrubute images to the Shared Image Gallery.
Then comes some ARM editing, as we have to change the original ARM templates to include Shared Image Gallery.
And the final step will be to do the deployment based on the new ARM templates

Create a Shared Image Gallery (SIG)

We start by creating a resource group to hold our Shared Image Gallery. I call it wvd-p-weu-sharedimagegallery-rg.

Then it’s a matter of creating our Shared Image Definition.

Go to All services and search for Shared Image Gallery. Hover over it, and select Create

After that select your new resource group, and give your Shared Image Gallery a name. I name it WVD_SharedImageGallery

When your SIG is done deploying you can go ahead and create one, or multiple, Image Definitions inside of it.

When on the Version tab, you can leave everything blank. We won’t be creating a version now. We will let Azure Image Builder do that for us.
When on the Publishing Options you can decide yourself what you fill in. This is just some metadata for other users who might use your images.

When done, we can go to the next step, and give Azure Image Builder rights to create images inside our Shared Image Gallery

Assign Azure Image Builder rights

Azure Image Builder uses a service principal to write to locations, as it doesn’t have rights on our SIG, we have to assign those.

You have to assign the App Id of AIB rights, which is always the following:
cf32a0cc-373c-47c9-9156-0db11f6a6dfc
I use PowerShell to assign Contributor rights to the resource group.

1
New-AzRoleAssignment -RoleDefinitionName "Contributor" -ApplicationId "cf32a0cc-373c-47c9-9156-0db11f6a6dfc" -ResourceGroupName wvd-p-weu-sharedimagegallery-rg

Distribute image to Shared Image Gallery

Now we have our Shared Image Gallery, it’s time to create an image with Azure Image Builder, and let it distribute to our Image Definition. In my previous blog I already showed how to create an image, but distributed it to a regular managed image. Now we just have to edit it, so AIB will distribute to Shared Image Gallery.

For that we have to edit the following part to the distribute section of our ARM template. You can find a prebuild template on my GitHub page

1
2
3
4
5
6
7
8
9
10
{
    "type": "SharedImage",
    "galleryImageId": "[parameters('SIGImageDefinitionId')]",
    "runOutputName": "SIGimage",
    "artifactTags": {
    },
    "replicationRegions": [
        "westeurope"
    ]
}

For the galleryImageId we have to get the Resource Id of our Image Definition, it can be found under the properties

As you can see, I choose westeurope as replicationregion. If you’re deploying VM’s from this image from multiple locations, you can specify more then one location here, for if you have hostpools in different parts of the world.

For the deployment I can use a parameter file, which is the preferred method. But for the sake of simplicity I’ll just pass my SIGImageDefinitionId parameter value on the commandline.

1
2
3
4
$TemplateUri = "https://raw.githubusercontent.com/Everink/AzureImageBuilder/master/Templates/AzureImageBuilde-SIG.json"
$ImageDefinitionId = "/subscriptions/f7e06285-03e5-4c9d-95cd-32d791b2563e/resourceGroups/wvd-p-weu-sharedimagegallery-rg/providers/Microsoft.Compute/galleries/WVD_SharedImageGallery/images/WVD-HostPool1-GoldenImage"

New-AzResourceGroupDeployment -ResourceGroupName RG_EUS_AzureImageBuilder -TemplateUri $TemplateUri -OutVariable Output -Verbose -SIGImageDefinitionId $ImageDefinitionId

After the image metadata has been made, we can start the image build.

1
2
$ImageTemplateName = $Output.Outputs["imageTemplateName"].Value
Invoke-AzResourceAction -ResourceGroupName RG_EUS_AzureImageBuilder -ResourceType Microsoft.VirtualMachineImages/imageTemplates -ResourceName $ImageTemplateName -Action Run

You can check the status of the build with the following command

1
(Get-AzResource -ResourceGroupName RG_EUS_AzureImageBuilder -ResourceType Microsoft.VirtualMachineImages/imageTemplates -Name $ImageTemplateName).Properties.lastRunStatus

The state should go from Building, to Distributing, to Succeeded. With me it took a total of 1 hour, as can be seen in the screenshots.

If you look in the portal afterwards, you should see an Image Version. AIB assigns a random version number, but newer versions should always be a higher version then the previous ones.

Edit the ARM template files

Note: This step is some technical stuff that explains what I changed, you can skip this if you just want to deploy from your Shared Image Gallery using my prebuild ARM template files.

Now we have our image in the Shared Image Gallery, we have to edit the templates to deploy a VM from it.

Normally when you deploy a hostpool from the portal, you get this wizard in which you fill out all configuration data, then some magic happens, and you get a new hostpool with some VM’s in it.

This magic isn’t really magic at all, because what happens is that in the background an ARM template gets deployed to your WVD resource group. And all that configuration data is inserted as parameters to that template.

You can find that template on GitHub: https://github.com/Azure/RDS-Templates/tree/master/wvd-templates/Create%20and%20provision%20WVD%20host%20pool

The ARM template is actually 1 main template, and a few other nested templates, based on what kind of image source you want. Either a gallery image or managed image for example. And based on that input data, it selects the nested template.
So what we have to do, is edit the templates a little bit to our needs.

The main part to edit has to be the imageReference, where normally this references an image from the gallery, now it references an image from our Shared Image Gallery. Next to that we also add some parameters to determine the resource ID of the Shared Image Gallery.

1
2
3
"imageReference": {
    "id": "[resourceId(parameters('SharedImageGalleryResourceGroup'),'Microsoft.Compute/galleries/images/versions',parameters('SharedImageGalleryName'), parameters('SharedImageGalleryDefinitionName'), parameters('SharedImageGalleryVersionName') )]"
},

To summarize the changes that I made:

Add my parameter file: mainTemplate.parameters.json
Added a new nested template file for sharedimage gallery deployments: managedDisks-sharedimagegalleryvm.json
Added parameters for the SIG resource in the file: mainTemplate.json
Added all SIG parameters also to the file: managedDisks-galleryvm.json, for consistency

To check all the changes, it’s best to look at the pull request on GitHub, to see everything that’s added to the original Microsoft template.

Deploying Windows Virtual Desktop VMs from Shared Image Gallery

Now, this previous step was some in-depth ARM template editing. If you’re not into all that, that’s fine. You are maybe more interested in how to use it, and that’s not too hard.

First you have to download 2 files from my GitHub account:

After that you have to edit the parameters file to your environment. It are basically the same parameters that you enter during the portal wizard.
Some things that are different is that I used a keyvault to store my passwords, so they aren’t in plaintext in my parameter file on the internet. If you only save the files locally on your own pc, you could just use plaintext passwords, but this isn’t recommended for production environments.

An explanation of the parameters can be found in the mainTemplate.json file, or my GitHub page

After you are done editing the parameter file, you are ready to deploy the VM’s to your hostpool!

For that you have to execute the following PowerShell commands

1
2
3
4
5
6
7
8
9
10
11
12
13
#Setup variables
$ResourceGroupName = "<WVD resourcegroupname>"
$TemplateFile = "<Path to mainTemplate.json>"
$TemplateParameterFile = "<Path to mainTemplate.parameters.json>"

#Install Module if you don't have it yet
Install-Module Az -Force

#Login to Azure RM
Add-AzAccount

#Start the deployment
New-AzResourceGroupDeployment -ResourceGroupName $ResourceGroupName -TemplateFile $TemplateFile -TemplateParameterFile $TemplateParameterFile -Verbose

This will take about 15 to 30 minutes to deploy, depending on the amount of servers you deploy.

Afterwards, you should be able to login, and have your desktop, with all applications and settings like you build it with Azure Image Builder.

If you now want to rollback to a previous image, the only thing you have to do is delete your VM’s from the portal and WVD backend, and do the deployment again, with only changing the version of your image!

Building a WVD image the right way

2019-11-10T00:00:00+00:00

Over the past few months I’ve seen multiple articles about how to create a Windows Virtual Desktop (WVD) image. They usually login to the VM themselves, install some apps and do some modifications, and sysprep the VM. After that you can optionally make a snapshot of your VM, and then convert it to a managed image which you can use for a WVD deployment.

Now, this is all good for a POC, demo or small production environment. But when things start to scale out, it just doesn’t cut it anymore. When building any type of image, you’d want the following things taken care off.

Consistent
Automated
Rollback procedure

You’d want consistency so you don’t accidental forget something in your golden image
Preferably you’d have something automate your creation of your image. Installing multiple pieces of software can be a tedious task, that time can be better spend doing something else. It also reduces the change of human error.
When you make a change to your golden image that breaks it, you’d better remember what you changed, and how to rollback to the previous state.

All those things can be solved by a single Azure service:
Azure Image Builder

Azure Image Builder (AIB) allows you to take a source image, which can be any of the following:

RHEL ISO
Marketplace image
Managed image
Shared Image Gallery image version

It then can customize that specific image to your needs in an automated way.
And as a final step AIB can distribute your image to any or multiple of the following:

Managed image
Shared Image Gallery
VHD in a storage account

You can see the overview in the following picture

Now, AIB is still in preview, so there are a few limitations to the service. It is limited to the following locations, but can still distribute outside of these locations.

East US
East US 2
West Central US
West US
West US 2

There is also no GUI (yet?) for Azure Image Builder
When building the image there is no way to check the progress, other then checking the logs manually, or checking if your image is already present at your distribution location.

With that bit of background info, lets start creating our own image with AIB!

Register the feature

To use Azure Image Builder during the preview, we have to first enable the service. We do that by registering the feature. This can be done with PowerShell, so we need to install the Az module within a privileged PowerShell windows, and after that we can login to our subscription

1
2
Install-Module Az -Force
Connect-AzAccount

When that is done, we can register the AIB feature with the following PowerShell command:

1
Register-AzProviderFeature -ProviderNamespace Microsoft.VirtualMachineImages -FeatureName VirtualMachineTemplatePreview

To check the status of the feature, run the following command

1
Get-AzProviderFeature -ProviderNamespace Microsoft.VirtualMachineImages -FeatureName VirtualMachineTemplatePreview

Note: It can take a while before the registrationstate will change to: Registered

After that make sure the following 2 commands also show Registred.

1
2
Get-AzResourceProvider -ProviderNamespace Microsoft.VirtualMachineImages | Select-Object RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.Storage | Select-Object RegistrationState

If there’s something showing NotRegistered run the following commands

1
2
Register-AzResourceProvider -ProviderNamespace Microsoft.VirtualMachineImages
Register-AzResourceProvider -ProviderNamespace Microsoft.Storage

When everything is done, you are ready for the next step!

Assign rights to AzureImageBuilder

During the previous step we enabled the feature, one of the things that happend, was that a service principal has been made in our Azure AD. This service principal (SP) is used to give AIB rights on certian resource (groups). The Application ID of the service principal is always the same:
cf32a0cc-373c-47c9-9156-0db11f6a6dfc

This SP needs rights on a resourcegroup that will be used for AIB. We first make this resourcegroup with the command:

1
New-AzResourceGroup -Name "RG_EUS_AzureImageBuilder" -Location 'East US'

The location needs to be in one of the supported AIB regions. Here I choose East US. Then we have to assign the contributor right to our SP for this resource group. You can do this with the portal, or also with the commandline.

1
New-AzRoleAssignment -RoleDefinitionName "Contributor" -ApplicationId "cf32a0cc-373c-47c9-9156-0db11f6a6dfc" -ResourceGroupName "RG_EUS_AzureImageBuilder"

Deploying AzureImageBuilder ARM template

When all permissions are in place it’s time to start with the deployment. This is done with an ARM template.
There is currently no portal experience for AIB.

The demo ARM template from Microsoft can be found on GitHub

If you look at the template you can see that on the properties part there are 3 sections

Source
Customize
Distribute

For source the best way to go in my opinion is to pick a marketplace image. These are tested by Microsoft, and are regularly updated to a new version. Of course you have to choose a new version every month or so.

In the Customize section you can customize your VM with a PowerShell script. This can be an external (publicly available) script, in a storage account or on GitHub. Or it can be an inline script if it’s only a few lines.

In the Distribute section you can define how and where to distribute your images. The most easy is to just deploy a managed image in the same resourcegroup as your AIB service.

If you want to use the Microsoft quickstart template, you can download it and edit the following parts:

Replace <subscriptionID> for your subscriptionID
Replace <rgName> for your AIB resourcegroupname
Replace <region> for a region OR replace it with a function that used the ResourceGroupFunction. That means replacing it for: [resourceGroup().location], including the square brackets
Replace <imageName> for a custom managed image name
Replace <runOutputName> for aibWindows (or something else you make up)

If however, you want to make use of another ARM template, I have one in my GitHub account as well, that uses parameters with some default values setup.

It will use the customize script that’s also in my GitHub account. It will install Visual Studio Code, Teams, Notepad++ and FSLogix.

To deploy this template use the following PowerShell commands

1
2
$TemplateUri = "https://raw.githubusercontent.com/Everink/AzureImageBuilder/master/Templates/AzureImageBuilder-ManagedImage.json"
New-AzResourceGroupDeployment -ResourceGroupName RG_EUS_AzureImageBuilder -TemplateUri $TemplateUri -OutVariable Output -Verbose

This will create an ImageTemplate package, which is linked to a new ResourceGroup IT_<AIB-resourcegroupname>_<AIB-imagetemplatename><random GUID>. In that resourcegroup it will setup all prerequisites, like downloading powershell scripts or files, and checking if AIB has all necessary rights on other resources (like Shared Image Gallery if you want to distribute to that)
It does not yet start building our image. It can be seen in the portal by selecting Show hidden items

In our previous PowerShell commandlet we used the output variable “Output”, to capture the name of our AIB imagetemplate. We can see it with

1
$Output.Outputs["imageTemplateName"].Value

We will use the imagetemplate name to start building our golden image. This can be done by invoking or executing the resource.

1
2
$ImageTemplateName = $Output.Outputs["imageTemplateName"].Value
Invoke-AzResourceAction -ResourceGroupName RG_EUS_AzureImageBuilder -ResourceType Microsoft.VirtualMachineImages/imageTemplates -ResourceName $ImageTemplateName -Action Run

This will start building the image.

To check the build status run the following command

1
(Get-AzResource -ResourceGroupName RG_EUS_AzureImageBuilder -ResourceType Microsoft.VirtualMachineImages/imageTemplates -Name $ImageTemplateName).Properties.lastRunStatus

When the build is complete there will be a managed image in our resource group, and we can start deploying VM’s from it!

When we login to the VM, we can see that the C:\temp folder has been populated with all the installers, and applications like team have also been installed to our image, just like we wanted.

You can now create different build templates for your different Windows Virtual Desktop hostpools, or create a default server VM image for your IaaS workloads.

If you have any questions, feel free to leave a comment below, or find me on LinkedIn.

My first blog!

2019-10-31T00:00:00+00:00

So I’ve been thinking about starting my own blogsite for a while now. I’ve some great idea’s about how to setup Windows Virtual Desktop, create the golden image for it, and enhance the default configuration.

Knowing myself, when my blog is online, I usually don’t bother too much with updating and maitenance. Also as it won’t generate a lot of traffic right away I don’t want to spend a lot of money on hosting. So that brings us to the following requirements

Low maintance
Low cost
Simple to setup
Scalable for if it will be a success

At first wordpress.com seemed like a good choice, untill I found out about Yekyll and github pages. Github can serve my blog just fine, it’s low maintance as it only serves up plain html, and costs nothing! It’s also highly scalable, and it gives me the option to checkin my blogs in source control.

So there you have it. You can find the sourcecode of my website in my github account.

Azure AD FIDO2 Authentication

2019-07-15T00:00:00+00:00

FIDO2 authentication is the latest method to sign in passwordless on devices and websites.

It was already possible for a few months to login passwordless with Microsoft accounts with a FIDO2 security key, but recently Azure AD FIDO2 authentication is in public preview.

In this blog I will show you how to setup your own tenant and device so you can leverage passwordless signin to Azure AD with FIDO2

What is FIDO2

FIDO stands for: Fast Identity Online

FIDO has been founded by the FIDO Alliance. The FIDO Alliance is an open industry association with a focused mission: authentication standards to help reduce the world’s over-reliance on passwords.

FIDO2 is the overarching term for FIDO Alliance’s newest set of specifications. FIDO2 enables users to leverage common devices to easily authenticate to online services in both mobile and desktop environments. The FIDO2 specifications are the World Wide Web Consortium’s (W3C) Web Authentication (WebAuthn) specification and FIDO Alliance’s corresponding Client-to-Authenticator Protocol (CTAP).

This makes it possible to login to services as Azure AD, or a random website, with a simple USB key, smartcard or even your phone.

This is based on the device that carries your credentials, combined with something you know or are. Like a PIN or a fingerprint

Downsides of passwords

Passwords are everywhere, because they are so simple to implement. But that simple implementation can also have it downsides!

Passwords are often reused
Because we need so many passwords, they are often recycled for different services. So when 1 password is compromised, multiple services are often at risk because the same password could be used for those as well.

Vulnerable to database hacks
Passwords are based on a pre-shared key. So the online service has a copy of your password, or a hashed version of your password. These databases can be compromised, so an attacker can find out your password

Vulnerable to Brute Force attacks
Passwords need to be remembered, so are often easily breached by a brute force or dictionary attack.

Vulnerable to social engineering attacks
This could be a simple as watching over someone shoulder as he/she types the password, or by guessing the password based on data found on social media.

Vulnerable to keyloggers
Regular passwords are vulnerable for keyloggers, this could be a hardware based keylogger between the PC and keyboard, but also a software keylogger. These record all keystrokes, including your password

Benefits of FIDO2 (password-less)

With FIDO2 all downsides of passwords are non-existent. This is because of the following.

Public / private keys
FIDO2 does not use a pre-shared key, but it uses public / private key pairs.

The public key is handed to the identity provider (like Azure AD), and the private key stays on the device, and will never leave it. It will only be used to sign a challenge.

So even if your public key gets stolen it’s no problem, because it’s useless. That’s what makes it a public key after all.

Unique keypairs
Where passwords are often reused for different services, that isn’t the case with FIDO2. For every online identity a new key pair is generated. So every identity has its own public and private key.

Phishing is part of the past
Because your identity and keypair is linked to a login domain (like login.microsoft.com), a challenge from a phishing site won’t be recognized by your FIDO2 key. A phishing site will try to let your login to login.micr0s0ft.com for example, and your FIDO2 key won’t have a keypair for that login domain.

Social engineering
You will not be vulnerable to social engineering attacks, as there is nothing to guess. You don’t even know your own private key. And if you use a FIDO2 key with a fingerprint there is also nothing to see when you login. So no more looking away for your colleagues.

Requirements

To enable FIDO2 authentication there are a few requirements.

Enable combined registration (preview)
Windows 10 1809 or higher met Microsoft Edge
Compatible FIDO2 security key

For Windows sign in:

Azure AD joined Windows 10 1809 or higher

Enable combined registration preview

The possibility to register a security key is only available in the new registration portal. That’s why we have to enable this feature first.

To to this login to https://portal.azure.com with a global administrator account. Go to User Settings -> Manage user feature preview settings

Make sure you select All or Selected for the feature:

Users can use preview features for registering and managing security info – enhanced

If you choose Selected you can select a pilot group first. Then click on Save

Enable FIDO2 authentication

To enable FIDO2 as an authentication method we login to the azure portal with a global administrator account. Then go to Azure Active Directory -> Authentication Methods

Then click on FIDO2 Security Key

At ENABLE click Yes

At TARGET I selected All users. It is possible to select a pilot group or user here. Then click on Save

User registration and management of security keys

To register a security key as a user, you can go to the following page: http://aka.ms/setupsecurityinfo

Click on Add method

Then choose the option: Security Key and click on Add

As my FIDO2 key is a USB device, I pick that.

After that I have to take action on my security key. This is dependent on how your key is configured and which features it supports I have a Feitian Biopass with a fingerprint reader which is sufficient for me. Sometimes there’s only a single button on it, and you have to enter a PIN as additional verification.

You can also see that the public / private key pair will be made for login.microsoft.com, so the key pair will only work for this site.

You can give your security key a descriptive name to identify it more easy. I call it: FeitianBiopass-Roel

Then the key is ready for use!

To login to a website with our key we can go to any Microsoft page where we can login with our Azure AD account. Like https://myapps.micosoft.com, https://outlook.office.com, or https://office.com

Click on Sign-in options

And then Sign in with a security key

Then follow the instructions to insert your key, and take action.

And with that we signed in to our account, without using our username or password!

To login to Windows 10 with a security key, we have to enable this feature first. You can do this in two ways:

credential provider via Intune
credential provider via provisioning package

I go for option 1, via Intune

The reason for this is that my device has to be Azure AD joined anyway, and it’s a small effort to do the Intune configuration compared to the provisioning package. It’s also more scalable with Intune

Go to the Azure portal, and search for Intune(or click here for the direct link)

Go to Device configuration -> Profiles -> Create profile And make a profile with the following settings:

Name: [profilename]
Description: [Description of the profile]
Platform: Windows 10 and later
Profile type: Custom

You have to add a new OMA-URI at settings. Click on Add And fill out the following fields:

Name: [Name of the setting]
Description: [Description of the setting]
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
Data type: Integer
Value: 1

Go to Assignments At Assign to select All Users & All Devices, or optionally select a pilot group or user

As soon as these settings are pushed to our device it’s possible to sign in to windows with our FIDO2 security key For this, click on Sign-in Options, and choose the USB symbol (FIDO security key)

Next we can authenticate on your security key, and we will be signed into Windows, again, without using our username or password!

This completes our full setup. We can now sign in to our device and to web pages with our security key and enjoy the benefits of passwordless authentication!

Step by step: Windows Virtual Desktop and FSLogix

2019-04-02T00:00:00+00:00

21 March 2019 the Windows Virtual Desktop preview went live. My colleague Jan Bakker and myself went straight to all available documentation, and build a test environment together. In this blogpost we will show you how to setup a Windows Virtual Desktop (WVD) environment, and what to watch out for. As a bonus we will also show how to install and configure FSLogix. This tutorial will be a step by step guide to setup a complete demo environment from scratch.

What is Windows Virtual Desktop?

Windows Virtual Desktop is a new service from Microsoft and enables you to deliver a virtual desktop from the Azure cloud. This could be a multi-user Windows 10 desktop, but also Windows 7 (with extended support) is possible. It also gives you the ability to install Office 365 ProPlus on the virtual desktops. Windows Virtual Desktop is a scalable service to deploy virtual machines, made possible by Azure resources, storage and advanced networking. The back-end like RDS brokers, gateways, web access, databases, and diagnostics are hosted and managed by Microsoft.

1. Requirements

To use Windows Virtual Desktop there are some requirements:

Active Directory Domain Services
An Azure tenant
An Azure subscription with credits.

The virtual machines that are deployed have to be domain joined, or be hybrid domain joined. Azure AD join is not (yet?) possible. So Windows Virtual Desktop is depending on an Active Directory domain. The VM’s will be joined to this domain, and with the use of AD Connect, you can login with your own Azure AD credentials. There are 3 options for Active Directory Domain Services:

Install / Enable Azure Active Directory Domain Services in your Azure subscription
Install the Active Directory Domain Services role on a server in Azure
Connect your own on-premises network with Active Directory to your Azure tenant with a Site-2-Site VPN or ExpressRoute connection

In this blog we choose option 2: We install a Windows Server 2019 VM and install the ADDS role.

2. Create azure tenant & subscription

In this blog we start from scratch. We’ll show you how to deploy Windows Virtual desktop in a greenfield environment. So we start with requesting a 30-days Azure trial subscription. You can request your trial here: https://azure.microsoft.com/nl-nl/free/

Follow the steps to create the trial subscription. You’ll also need a creditcard. No worries, this is only for verification, no actual costs will be charched.

Because we will need an internet routable domainname, we will add this right away to our Azure AD tenant. This domainname we will also use for our Active Directory domainname. This isn’t necessary, but it will make sure we have an easier domainname for our Azure AD users.

We’lll use the domainname: resultaatgroep.eu

HINT: You can also use the standard extension: tenantname.onmicrosoft.com Your own domain is optional.

As soon as we added the custom domainname, we have to create a TXT record in the public DNS console to validate the domain, and after that we can start creating users with the suffix: @resultaatgroep.eu

3. Installing Active Directory Domain Services

To deploy Active Directory we first need a server in our subsciption. We’ll also need a network to which the server can connect to. However, we can create the network during the VM creation wizard.

To to: “Virtual Machines”, and click on “+ Add”

Then follow the steps to deploy a Windows Server 2019 Datacenter VM.

Create during the wizard also an extra datadisk. We’ll need the disk to create the Active Directory Domain Services database on.

NOTE: we give our VM a public IP adres, this is not recommended in a production environment.

If you do this, make sure you apply a Network Security Group that allows only RDP connections from your own WAN address. You could optionally also create a Point-2-Site VPN connection

For more information: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-portal

When your VM is done, go to “Virtual Machines” –> [VM naam] and note the private IP address. By default the vNet in Azure will give give the Azure DNS servers to servers. As we will install Active Directory Domain Services & DNS on our VM, we can change the DNS server of the vNet already to the IP address of our VM.

Go to Virtual Networks and click on your vNet. At the section DNS servers you can fill out your own DNS server, use the private IP address of your VM that will host the DNS server role.

When this is done, go to your VM again and click on Connect to download the RDP file, and login to your VM

Next you can install Active Directory Domain Services. In our demo we’ll use PowerShell for this. As a best-practice, make sure all data is on a datadisk, and not on an OS disk. This also goes for the AD database, log directory and sysvol directory. Change the values to your own domain, and check if the datadisk (here with F:\) is visible

1
2
3
4
5
6
7
8
9
10
11
12
13
$securestring = ConvertTo-SecureString -AsPlainText -Force -String *********
Install-windowsfeature -name AD-Domain-Services -IncludeManagementTools

$parameterSplat = @{
    SysvolPath = "F:\\SYSVOL"
    LogPath = "F:\\NTDS"
    DatabasePath = "F:\\NTDS"
    DomainNetbiosName = "RESULTAATGROEP"
    DomainName = "resultaatgroep.eu"
    Force = $true
    SafeModeAdministratorPassword = $securestring
}
Install-ADDSForest @parameterSplat

Create OU for the Windows Virtual Desktop VM’s

Now Active Directory has been installed and ready for use we can create a couple of OU’s that will house our WVD servers, and our users. We will also do this with PowerShell, but you can also do this with the GUI.

1
2
3
4
5
New-ADOrganizationalUnit -Name ResultaatGroep -Path "DC=resultaatgroep,DC=eu"
New-ADOrganizationalUnit -Name Groups -Path "OU=ResultaatGroep,DC=resultaatgroep,DC=eu"
New-ADOrganizationalUnit -Name Users -Path "OU=ResultaatGroep,DC=resultaatgroep,DC=eu"
New-ADOrganizationalUnit -Name Servers -Path "OU=ResultaatGroep,DC=resultaatgroep,DC=eu"
New-ADOrganizationalUnit -Name "Windows Virtual Desktops" -Path "OU=Servers,OU=ResultaatGroep,DC=resultaatgroep,DC=eu"

Creating testaccounts

To login at our Virtuele Desktops, we create a couple of testaccounts. You’ll need these before you create the WVD hostpool, as you need to supply users during the wizard.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
$newADUserSplat = @{
    Path = "OU=Users,OU=ResultaatGroep,DC=resultaatgroep,DC=eu"
    ChangePasswordAtLogon = $false
    UserPrincipalName = "jan@resultaatgroep.eu"
    GivenName = "Jan"
    AccountPassword = (ConvertTo-SecureString -AsPlainText -Force -String "******")
    SamAccountName = "jan"
    DisplayName = "Jan Bakker"
    Name = "Jan Bakker"
    Enabled = $true
    Surname = "Bakker"
}
New-ADUser @newADUserSplat

$newADUserSplat2 = @{
    Path = "OU=Users,OU=ResultaatGroep,DC=resultaatgroep,DC=eu"
    ChangePasswordAtLogon = $false
    UserPrincipalName = "roel@resultaatgroep.eu"
    GivenName = "Roel"
    AccountPassword = (ConvertTo-SecureString -AsPlainText -Force -String "******")
    SamAccountName = "roel"
    DisplayName = "Roel Everink"
    Name = "Roel Everink"
    Enabled = $true
    Surname = "Everink"
}
New-ADUser @newADUserSplat2

4. Installing Azure AD Connect

Next we will install Azure AD Connect to synchronize our Active Directory with Azure Active Directory.

You can download the install file here: https://www.microsoft.com/en-us/download/details.aspx?id=47594

To save cost, we will install this on our Domain Controller.

Download the installfile and execute it, wait till the wizard starts.

We choose for “Use express settings”. You can pick Customize if needed for OU filtering or other settings. For our demo this isn’t important.

During the install you will be asked for Azure AD credentials and ADDS credentials

For Azure AD you’ll need Global Admin rights, and for ADDS you’ll need an Enterprise Administrator.

After the install the synchronize will start automatically. You can check in your Azure AD tenant if the sync was succesfull.

5. Configure Windows Virtual Desktop

To use Windows Virtual Desktop (WVD) there are a few steps to be taken to give the back-end service and web client rights to your Azure AD tenant.

The WVD back-end and client app are multi-tenant enviroments which are managed by Microsoft. That means that, by default, the WVD environment has no rights to our Azure tenant. There is also no WVD tenant for us yet.

So first we have to create the WVD tenant, and give rights to our Azure tenant.

Assigning rights to the WVD back-end & client app

to go the site: https://rdweb.wvd.microsoft.com/

first, select here “Server App” and fill in your Tenant ID.

Then wait about 30 seconds, and select: “Client App” with the same Tenant ID.

You can find your Tenant ID at the following location:

“Azure Active Directory” –> “Properties” –> “Directory ID”

Creating the WVD tenant

Creating the tenant is done on the server back-end, which we just gave rights to our Azure tenant.

We just have to give a user (or service principal) rights to create the actual WVD tenant. Go in the Azure portal to: “Azure Active Directory” –> “Enterprise Application”

In the list are 2 applications: “Windows Virtual Desktop” & “Windows Virtual Desktop Client”

These have been created because we gave them access to our Azure tenant in the previous step.

Click on:“Windows Virtual Desktop” –> “Users and groups” and click on: “Add user”

At role there is only one option and its preselected: TenantCreator. Select one or multiple users who can create a tenant. And click on “Assign”

Create the tenant with the following commands: The AadTenantId we already have from the previous steps

You can find the subscriptionId in the portal: “All Services” –> “Subscriptions” –> “Subscription ID”

Because we will login at the back-end, we can also create a service principal which has rights to create host pools in WVD, and to add servers to the hostpools

You can use the service principal because later during the WVD wizard you’ll use an account to create the host pools. And MFA enabled accounts aren’t supported. If you use a regular user account that isn’t MFA enabled you can skip creating the service principal.

Start PowerShell as administrator (to install modules) and execute the following commands (substitute variables for your environment):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Install-Module -Name Microsoft.RDInfra.RDPowerShell, AzureAD
Import-Module -Name Microsoft.RDInfra.RDPowerShell, AzureAD

#Setup variables, tenantName will be the name of our WVD tenant
$tenantName = "ResultaatGroep-WVD"
$AadTenantId = "11111111-2222-3333-4444-555555555555"
$subscriptionId = "11111111-2222-3333-4444-555555555555"

#Login at the WVD back-end (with the account that has TenantCreator rights)
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"

#Creating the RDS tenant
New-RdsTenant -Name $tenantName -AadTenantId $AadTenantId -AzureSubscriptionId $subscriptionId

#Login to Azure AD with a global admin account to create a service principal
$aadContext = Connect-AzureAD

#Creating theservice principal with credentials
$svcPrincipal = New-AzureADApplication -AvailableToOtherTenants $true -DisplayName "Windows Virtual Desktop Svc Principal"
$svcPrincipalCreds = New-AzureADApplicationPasswordCredential -ObjectId $svcPrincipal.ObjectId

#Assign rights to the service principal
New-RdsRoleAssignment -RoleDefinitionName "RDS Owner" -ApplicationId $svcPrincipal.AppId -TenantGroupName "Default Tenant Group" -TenantName $tenantName

#Make sure the credentials of the sevice principal are saved, you can see these with:
$svcPrincipal.AppId
$svcPrincipalCreds.Value

You’ll need the password and AppId in the next step.

Note: The next step is creating the hostpool, if you want to test FSLogix and Office 365 on your VM’s right away, then take the nessicary steps from chapter 7 first. There we will create install scripts for Office and the FSLogix agent, and we’ll configure it with Azure Blob storage. Offcourse, these steps can also be done afterwards.

Creating the hostpool

And now the creation of the Windows Virtual Desktop Hostpool. This is done from the Azure portal.

Choose: + Create a resource and search for Windows Virtual Desktop. Choose for: Windows Virtual Desktop – Provision a host pool

Then choose for Create

Choose a Poolname, and pick your type. We go for Pooled, but you can also create peronal VM’s

Then fill in your testusers that you made earlier. These users will be linked to this pool and can use its resources.

Fill in the Resource Group op. It has to be empty.

Then you assign the location.

In this windows we will determine the amount and type of VM. You can choose at will, for our test 1 VM of type D2s_v3 will suffice.

Also fill in the prefix for your VM’s.

More information about scaling and pricing can be found here.

Here we will determine the OS verion, domain and the vNet

We choose for the standard Gallery sourceWindows 10 Enterprise multi-session.

We also fill in the info to join our VM to the domain: resultaatgroep.eu.

Note: the vNet you select here has to be able to reach your domain controller

In this step you fill out your tenant group name and tenant name. You created this earlier and has to match.

Also fill out your RDS Owner, this could be a (non MFA enabled) users, but in our case we use the Service Principal that we created earlier.

We also fill out our Azure AD tenant ID.

In step 5 there’s a validation and summary of our steps, check this one final time and choose Next to finish the wizard

You can follow the status of your deployment under Deployments while inside your Resource Group.

At the moment of writing this, it is not yet possible to give a group rights to a hostpool, only users can be granted rights to a hostpool

6. Connecting to Windows Virtual Desktop

You can connecto to Windows Virtual Desktop in 2 ways, will we show both.

HTML 5 browser

The easiest method is the browser. Go to https://rdweb.wvd.microsoft.com/webclient and login with your testuser.

Unfortunatly SSO doesn’t work yet, that means that you have to login to Azure AD first, and after selecting your desktop or application, you have to login to the server.

With ADFS it is possible to create an SSO experience.

Windows client – Remote Desktop

You can also download the Windows client. The benefit is that it performs a bit better, and you get start menu integration.

You can download the client here

After the install you can choose Subscribe. then login with the testuser. testgebruiker.

6. Optional: Virtual Desktop VM’s & FSLogix

We also want to show you how to install and configure FSLogix. This step is optional, but certainly a good thing to do. With FSLogix you can store the profile, and with it, the Outlook/OneDrive cache and the searchindex in a separate VHDX that will connect to your session at logon time.

The VHDX is normally on an SMB fileshare on a server, but FSLogix also supports Azure page block storage! As we dont need a fileserver for the Azure storage that we’ll have to maintain and will incur compute cost, this is the best option for us! We recommend to first read the FSLogix documentation if you’re not yet familiar with it.

For all next steps goes: these are for our demo environment, some of these are not recommended for a production environment.

Storage account for the Profile Containers

We start with creating the Azure Storage Account. This will house the FSLogix VHDX files. If you prefer an SMB share that is also possible, then create a fileshare with these instructions: https://docs.fslogix.com/display/20170529/Requirements+-+Profile+Containers

Go to the Azure portal to create the storage account. Click on “Create a resource” Search for: “Storage account” and click on: “Create”

Follow the wizard to fill out all fields. We chose for premium storage, so the user experience is as fast as possible

We also only allow access from the subnet in which our Virtual Desktops will reside. This will also mage sure that a Storage Endpoint will be added to this subnet, so the latency to the storage will be as low as possible. The full settings are in the screenshot below.

GPO – Install FSLogix Agent

To install the FSLogix agent we use a group policy. You can download the software from https://go.microsoft.com/fwlink/?linkid=2084562

From the ZIP file you’ll need the FSLogixAppsSetup.exe and the TXT file with the licence. We also need the ADMX and ADML files to create the GPO for the agent settings.

Update: You don’t need a license anymore to install FSLogix, so that part is obsolete.

Make a new GPO under the OU that we created earlier. Go to Computer Configuration -> Windows Settings -> Scripts -> Startup. Click on Show Files and place the .EXE in the folder.

Next click on Add and add the .EXE. In the parameter field fill in: /silent ProductKey=MSFT0-YXKIX-NVQI4-I6WIA-O4TXE

Import ADMX files

Copy the file “fslogix.admx” (from theZIP file) to C:\Windows\PolicyDefinitions on your domaincontroller. Copy the file “fslogix.adml” to the C:\Windows\PolicyDefinitions\en-us\ folder.

GPO – Configure FSLogix Agent

To configure FSLogix we also make a group policy. Under Computer Configuration -> Policies -> Adminstrative Templates you can find the FSLogix settings.

Configure at least the following:

Computer Configuration -> Policies -> Administrative Templates -> FSLogix/Profile Containers

Setting	Value
Enabled	Enabled
Size in MB’s	25600
Delete local profile when FSLogix Profile should apply	Enabled (be carefull with this setting in production environments)

Computer Configuration -> Policies -> Administrative Templates -> FSLogix/Profile Containers/Advanced

Setting	Value
Locked VHD retry count	1
Locked VHD retry interval	0

Computer Configuration -> Policies -> Administrative Templates -> FSLogix/Profile Containers/Cloud Cache

Setting	Value
Cloud Cache Locations *	type=azure,connectionString=”XXXXXXX”

Computer Configuration -> Policies -> Administrative Templates -> FSLogix/Profile Containers/Container and Directory Naming

Setting	Value
SID directory name matching string	%userdomain%-%username%
SID directory name pattern string	%userdomain%-%username%
Virtual disk type	VHDX

* Replace the value XXXXXX for your own personal connection string of the storage account that you created earlier

Creating Include and Exclude Groups (Optional)

By default there are 4 local groups so FSLogix is enabled for everyone. To determine who will be enabled for FSLogix Profile Containers and who will be disabled you can create 2 AD groups. We will add these to the groups which FSLogix made locally on the server(s). That way we can disable FSLogix for our domain admins or specific users.

Make 2 groups in AD: FSLogix AD Profile Exclude List & FSLogix AD Profile Include List. Make the AD group “Domain Admins” member of the exclude group, and add your testusers to the include group.

Then make a new GPO and add the AD groups to the local groups. The names of the local groups are: FSLogix Profile Include List & FSLogix Profile Exclude List. Enable the option to delete all members of the group

Office Deployment Tool

If you have a valid Office 365 license, you can also test with Office 365 ProPlus. For this we create a GPO that will install this during boot. We used the website https://config.office.com/ to create an XML for our install. Make sure you enable “Shared Computer Activation”, else the software doesn’t work properly on a multi-user environment. In our config we made a selection of a couple of products. The other applications will not be installed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<Configuration ID="a02f45f4-6a0e-4215-85af-e2458dabbcf4" DeploymentConfigurationID="00000000-0000-0000-0000-000000000000">
    <Add OfficeClientEdition="64" Channel="Insiders" ForceUpgrade="TRUE">
    <Product ID="O365ProPlusRetail">
        <Language ID="MatchOS" />
        <ExcludeApp ID="Access" />
        <ExcludeApp ID="Groove" />
        <ExcludeApp ID="Lync" />
        <ExcludeApp ID="OneNote" />
        <ExcludeApp ID="Publisher" />
    </Product>
    </Add>
    <Property Name="SharedComputerLicensing" Value="1" />
    <Property Name="PinIconsToTaskbar" Value="TRUE" />
    <Property Name="SCLCacheOverride" Value="0" />
    <Updates Enabled="TRUE" />
    <RemoveMSI />
    <AppSettings>
        <Setup Name="Company" Value="ResultaatGroep" />
    </AppSettings>
    <Display Level="Full" AcceptEULA="TRUE" />
</Configuration>

To install Office you need the Office Deployment Tool. You can download it from here: https://www.microsoft.com/en-us/download/details.aspx?id=49117

Extract the files, you will need the “setup.exe” and the earlier made “Configuration.xml” in the next step.

GPO – Install Office 365 ProPlus

Make a new GPO. Go to Computer Configuration -> Windows Settings -> Scripts -> Startup and place, like before with the FSLogix agent, now the setup.exe and the configuration.xml in the folder.

Then click on Add and choose the setup.exe file. And the script parameter field you enter: /Configure Configuration.xml

Now link the GPO to the OU that you made before for your Windows Virtual Deskop VM’s.

Office 365 ProPlus settings for Outlook (Optional)

This step is optional. You can also configure the cache manually on the clients

To configure the cache we create a GPO based on the Office 365 ProPlus ADMX files. You can download the files from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=49030

Copy at least the ADMX and ADML of Outlook to C:\Windows\PolicyDefinitions on your domain controller.

Note, this time we use the User Configuration section to force the cache settings

Make a new GPO and configure as following:

User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2016/Account Settings/Exchange/Cached Exchange Mode

Setting	Value
Cached Exchange Mode Sync Settings	Enabled
Select Cached Exchange Mode sync settings for profiles	determine yourself
Use Cached Exchange Mode for new and existing Outlook profiles	Enabled

Rebooting Server(s)

When all GPO’s have been made, you’ll have to reboot your servers. During booting the FSLogix agent and Office 365 will be installed. This will take a couple minutes ofcourse, but nothing too long, as your VM’s are connected to the Microsoft backbone.

After this you can login and configure Outlook and OneDrive for use. Offcourse your account needs a valid license for this.

VHDX location

Now check the Azure portal if you can see the VHDX. If you did everything correct it will look like this:

Troubleshoot Profile containers

With the FSLogix software a tool will be installed to easily read the FSLogix logging. It’s located on the following location: “C:\Program Files\FSLogix\Apps\frxtray.exe”

TIP: Copy this tool to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. This will make it start for all users

7. More info

We used the below sources for making this blog.

FSLogix Documentation

Windows Virtual Desktop Documentation

For questions or remarks you can reach us through LinkedIn.

Roel Everink	Jan Bakker

roeleverink.nl

PowerShell Function app behind Azure AD authentication

Table of Contents

1. Setup

2. Creating the Function App

3. Creating a Managed Identity

4. Creating the first function

5. Creating the second function

6. Add AzureAD authentication

7. Group or user based access

Deploy a Shared Image Gallery image to Windows Virtual Desktop

Table of Contents

Create a Shared Image Gallery (SIG)

Assign Azure Image Builder rights

Distribute image to Shared Image Gallery

Edit the ARM template files

Deploying Windows Virtual Desktop VMs from Shared Image Gallery

Building a WVD image the right way

Register the feature

Assign rights to AzureImageBuilder

Deploying AzureImageBuilder ARM template

My first blog!

Azure AD FIDO2 Authentication

Table of Contents

What is FIDO2

Downsides of passwords

Benefits of FIDO2 (password-less)

Requirements

Enable combined registration preview

Enable FIDO2 authentication

User registration and management of security keys

Login to websites with a FIDO2 security keys

Login to Windows 10 with a FIDO2 security keys

Step by step: Windows Virtual Desktop and FSLogix

Table of Contents

1. Requirements

2. Create azure tenant & subscription

3. Installing Active Directory Domain Services

Create OU for the Windows Virtual Desktop VM’s

Creating testaccounts

4. Installing Azure AD Connect

5. Configure Windows Virtual Desktop

Assigning rights to the WVD back-end & client app

Creating the WVD tenant

Creating the hostpool

6. Connecting to Windows Virtual Desktop

HTML 5 browser

Windows client – Remote Desktop

6. Optional: Virtual Desktop VM’s & FSLogix

Storage account for the Profile Containers

GPO – Install FSLogix Agent

Import ADMX files

GPO – Configure FSLogix Agent

Creating Include and Exclude Groups (Optional)

Office Deployment Tool

GPO – Install Office 365 ProPlus

Office 365 ProPlus settings for Outlook (Optional)

Rebooting Server(s)

VHDX location

Troubleshoot Profile containers

7. More info