This is part 2 of our posts regarding Windows Virtual Desktop, until now we have covered:
- Part 1 – Created a Windows Virtual Desktop tenant – http://blog.mindcore.dk/2019/11/windows-virtual-desktop-part-1.html
Now let’s continue and create a service principal.
We will create the service principal with PowerShell, in order to do that you will need the AzureAD module.
You can always see latest version of both the General Availability version (AzureAD module) and the preview version (AzureADPreview module) here https://docs.microsoft.com/en-us/powershell/azure/active-directory/ad-pshell-v2-version-history?view=azureadps-2.0
To see your current version use the commands:
Import-Module -Name AzureAD or Import-Module AzureADPreview (depending on which module you want to use)
Get-Module -Name AzureAD or Import-Module AzureADPreview (depending on which module you want to use)
You can always just uninstall and reinstall the module to be sure you got the latest version. (elevated)
Uninstall-Module -Name AzureADPreview
Install-Module -Name AzureADPreview
Now login to the Azure AD tenant with the command.
And enter credentials.
We also need the Windows Virtual Desktop module we installed in Part 1, so let’s import that.
Now sign in to Windows Virtual Desktop.
Add-RdsAccount -DeploymentUrl https://rdbroker.wvd.microsoft.com
Use your account with the TenantCreator role.
Now that we are connected to Azure AD, let’s create a multitenant service principal in our Azure AD.
$AzureADServicePrincipal = New-AzureADApplication -AvailableToOtherTenants $true -DisplayName "Windows Virtual Desktop Service Principal"
Save credentials for use in the next command.
$AzureADServicePrincipalCredentials = New-AzureADApplicationPasswordCredential -ObjectId $AzureADServicePrincipal.ObjectId
Later we will need the enter the password, so it’s important to save it because we won’t be able to retrieve it after we close this PowerShell session, we can however later reset it with New-AzureADApplicationPasswordCredential.
Use this command to see the password and save it.
In the Azure portal – Azure Active Directory – App registrations you will now see our service principal.
Next we assign the role RDS Owner to the service principal so it can sign in to Windows Virtual Desktop.
New-RdsRoleAssignment -RoleDefinitionName "RDS Owner" -ApplicationId $AzureADServicePrincipal.AppId -TenantName (Get-RdsTenant).TenantName
We need to test our service principal, use the following code.
$credentials = New-Object System.Management.Automation.PSCredential($AzureADServicePrincipal.AppId, (ConvertTo-SecureString $AzureADServicePrincipalCredentials.Value -AsPlainText -Force))
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com" -Credential $credentials -ServicePrincipal -AadTenantId (Get-AzureADCurrentSessionInfo).TenantId.Guid
Notice that this time no userName is displayed when connecting, the command Get-RdsTenant will return information if our account works.
Then we will do some preparation in our on-premises Active Directory.
In this test we will use an OU called WVD in the domain lab.local (OU=WVD,DC=lab,DC=local), this will hold our deployed machines.
When joining computers to the domain we will use a service account called svc-wvd-domainjoin.
For the OU=WVD we have delegated control so that the service account can create new computers (Minimal permissions to join the domain).
Finally we need a test user in Active Directory which is synchronized to Azure AD, so we create a user called email@example.com.
And makes sure that the account is synchronized to Azure AD and assigned an Office 365 E3 or E5 license.
With this in place we are ready to create a host pool, stay tuned for part 3.