Windows Virtual Desktop - New-RdsTenant throws error "User is not authorized to query the management service." due to Azure AD permission error.

When you try to create a new Windows Virtual Desktop tenant you run the command

New-RdsTenant -Name "Windows Virtual Desktop Betts" -AadTenantId "xxxxx" -AzureSubscriptionID "xxxxxx"

And are faced with the error "New-RdsTenant : User is not authorized to query the management service.". This is due to a permission configuration problem on Azure AD. 

Before you get to the stage of creating a new WVD tenant you must complete the consent process to grand access to your AAD tenant, this can be done here https://rdweb.wvd.microsoft.com/

Once it is done you will notice two new objects under Enterprise Applications for Windows Virtual Desktop, click on the first one. 

You must add a new user account with TenantCreator permissions before you can create a new WVD tenant. Please note that the Global Admin account for the directory does not work, it must be TenantCreator. 

Once you have a TenentCreator, ensure you authenticate to your directory at the Add-RdsAccount stage using this account before you attempt to create a new WVD tenant. This is where you will be faced with "User is not authorized to query the management service." even if you use a Global Admin account. 

How to convert Azure "unmanaged" Operating System disks to Managed Disks using Powershell

It is very easy to convert an "unmanaged" disk to a Managed Disk inside Azure, if the source VM is standalone and not part of an Availability Set. I recently had to do this after I had "lifted and shifted" a handful of VM's to Azure for a POC. The idea was that I would create new VM's from a specialised VHD's which were uploaded to Azure Storage. I did some research to see what the process was like for moving migrated VM's to Managed Disks.

The following PowerShell code can be used to convert a VM's unmanaged disk to a Managed Disk, please note that this will automatically convert all the associated data disks attached to the VM.

$rgName = "myResourceGroup" $vmName = "myVM" Stop-AzureRmVM -ResourceGroupName $rgName -Name $vmName -Force ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $rgName -VMName $vmName Start-AzureRmVM -ResourceGroupName $rgName -Name $vmName

The process takes some time to complete, mainly because Azure copies the VHD from the Azure Storage Account. However, it is very quick, my 45GB VM was converted in less than 5 minutes. Once the conversion is completed, the VM will start and the lease on the original VHD will be released. 

When you convert a VHD to a Managed Disk, the Managed Disk is automatically labelled the same name as the VM. It discounts the name of the source VHD from the storage account.

Configuring Extranet Lock Protection in ADFS 2016

Extranet Lock Protection is used to protect your Internet facing ADFS from password brute force attacks. Extranet Lock Protection works much like an Account Lockout Policy in Active Directory, you set a password attempt threshold in conjunction with a period of time before the user in question can be authenticated. With ELP enabled, even if the user attempts to login to the Sign In page using valid credentials after the threshold has been met and before the lock time has expired, they will not be granted access.

ADFS ELP works separately from Active Directory account lock outs, if you enable ELP it will not disable on premise user accounts if a brute force attack has been attempted at the ADFS Sign In page.

Some comparisons should be made between the AD Account Lockout Policy and ELP.

·      Lockout threshold on ELP should be less than the threshold in AD.

·      Lockout time window on ELP should be greater than the threshold in AD.

Extranet Lock Protection is not enabled by default on Server 2012 R2 or Server 2016.

View the default using Get-AdfsProperties

Enable Extranet Lockout Protection with a threshold of 3 wrong authentication attempts and a lockout observation window of 15 minutes.

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 3 -ExtranetObservationWindow (new-timespan -Minutes 15)

Run the command Get-AdfsProperties again to ensure the change has been applied.

It’s worth noting that it takes some time for the warning to disappear from the Azure AD Connect page inside the Azure Portal. It does not seem to be instant and nothing I did seemed to force a re-evaluation.

Further reading https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-lockout-protection