In this chapter, you will learn about all the identity options available in the Azure cloud, including which identity option is best for Azure Virtual Desktop. You’ll also learn about Azure Virtual Desktop licensing model/options, user profile storage plans, and network connectivity recommendations.
Let’s begin with the Azure Virtual Desktop licensing options.
Select an Appropriate Licensing Model for Azure Virtual Desktop Based on the Requirements
- BYOL Windows 10 and Windows 7: You are eligible to access Windows 10 and Windows 7 with Azure Virtual Desktop if you have one of the following per-user licenses:
Microsoft 365 E3/E5
Microsoft 365 A3/A5/Student Use Benefits
Microsoft 365 F3
Microsoft 365 Business Premium
Windows 10 Enterprise E3/E5
Windows 10 Education A3/A5
Windows 10 VDA per user
BYOL Windows Server: You are eligible to access Windows Server with Azure Virtual Desktop if you have a per-user or per-device RDS CAL license with active Software Assurance (SA).
Per user access pricing for external users: You can also pay a monthly per-user fee to access Azure Virtual Desktop for external users.
Recommended Storage Solution (Including Azure NetApp Files vs. Azure Files)
Operating system storage: For optimal performance, it is recommended that you use premium SSD storage for the Azure Virtual Desktop session host’s operating system disk for production workloads. The operating system disk size depends on the operating system and applications installed on the C: drive.
- User data storage
Storage for personal desktop: A personal desktop is a persistent desktop, meaning the user will get the same desktop every time they log in to Azure Virtual Desktop. The user can store data on the local VM. Additional standard or premium storage can be attached to the personal Azure Virtual Desktop instance to store user data or install applications.
Storage for pooled desktop user profile (pooled): Since pooled desktops are not persistent desktops, the user will not get the same VM every time they log in to Azure Virtual Desktop. Therefore, the user profile must be stored on remote storage using FSLogix. Pooled Azure Virtual Desktop supports FSLogix, which helps to store user profiles on Azure Files as well as Azure NetApp Files. Both Azure Files and NetApp Files support ADDS authentication as well as secure access over a virtual network, and it is recommended that you restrict the profile storage to a specific virtual network with a private endpoint. You can use a storage domain join so authorized users can access storage and user profiles.
Differences Between Azure Files and NetApp Files
Category | Azure Files | Azure NetApp Files (ANF) |
---|---|---|
Description | Azure Files is built on the same Azure storage platform as other services such as Azure Blobs. | ANF is built on NetApp’s bare metal with the ONTAP storage OS running inside the Azure datacenter for a consistent Azure experience and on-premises type of performance. |
Protocols | Premium. | All tiers. |
SMB 2.1, 3.0, 3.1.1. | SMB 2.x, 3.x. | |
NFS 4.1 (preview). | NFS 3.0, 4.1. | |
REST. | Dual protocol access (NFSv3/SMB). | |
Standard. | ||
SMB 2.1, 3.0, 3.1.1. | ||
REST. | ||
Region availability | Premium, 30+ regions. | All tiers, 28+ regions. |
Standard, all regions. | ||
Redundancy | Premium, LRS, ZRS. | All tiers, built-in local HA. |
Standard, LRS, ZRS, GRS, GZRS. | ||
Identity-based authentication and authorization | Active Directory Domain Services (AD DS). | Active Directory Domain Services (AD DS). |
Azure Active Directory Domain Services (Azure AD DS). | Azure Active Directory Domain Services (Azure AD DS). | |
Encryption | All protocols. | All protocols. |
Encryption at rest (AES 256) with customer or Microsoft-managed keys. | Encryption at rest (AES 256) with Microsoft-managed keys. | |
SMB. | SMB. | |
Kerberos encryption using AES 256 or RC4-HMAC. | Encryption in transit using AES-CCM (SMB 3.0) and AES-GCM (SMB 3.1.1). | |
Encryption in transit. | ||
Access options | Internet. | Secure VNet access. |
Secure VNet access. | VPN Gateway. | |
VPN Gateway. | ExpressRoute. | |
ExpressRoute. | Global File Cache. | |
Azure File Sync. | HPC Cache. | |
Data protection | Incremental snapshots. | Snapshots (255/volume). |
File/directory user self-restore. | File/directory user self-restore. | |
Restore to new location. | Restore to new volume. | |
In-place revert. | In-place revert. | |
Share-level soft delete. | Cross-Region Replication (public preview). | |
Azure Backup integration. | ||
Migration tools | Azure Data Box. | Global File Cache. |
Azure File Sync. | CloudSync, XCP. | |
Storage Migration Service. | Storage Migration Service. | |
AzCopy. | AzCopy. | |
Robocopy. | Robocopy. | |
Application-based (for example, HSR, Data Guard, AOAG). | ||
Tiers | Premium. | Ultra. |
Transaction Optimized. | Premium. | |
Hot. | Standard. | |
Cool. | ||
Minimum share/volume Size | Premium. | All tiers. |
100 GB. | 100 GB (Minimum capacity pool size: 4 TB). | |
Standard. | ||
No minimum. | ||
Maximum share/volume Size | 100 TB. | All tiers. |
100 TB (500 TB capacity pool limit). | ||
Up to 12.5 PB per Azure NetApp account. | ||
Maximum share/volume IOPS | Premium. | Ultra and Premium. |
Up to 100k. | Up to 450k. | |
Standard. | Standard. | |
Up to 10k. | Up to 320k. | |
Maximum share/volume Throughput | Premium. | Ultra and Premium. |
Up to 10 GB/s. | Up to 4.5 GB/s. | |
Standard. | Standard. | |
Up to 300 MB/s. | Up to 3.2GB/s. | |
Maximum file size | 4 TB. | 16 TB. |
Maximum IOPS per file | Premium. | All tiers. |
Up to 8,000. | Up to volume limit. | |
Standard. | ||
1,000. | ||
Maximum throughput per file | Premium. | All tiers. |
300 MiB/s (Up to 1 GB/s with SMB multichannel). | Up to volume limit. | |
Standard. | ||
60 MiB/s. | ||
SMB multichannel | Yes. | Yes. |
Latency | Single-millisecond minimum latency (2ms to 3ms for small I/O). | Submillisecond minimum latency (less than 1ms for random I/O). |
Plan for Azure Virtual Desktop Client Deployment
The Azure Virtual Desktop client helps end users to connect to the Azure Virtual Desktop instance assigned to them over the Internet/intranet. There are different Azure Virtual Desktop clients available based on the end-user device/operating system type. It is recommended to use a desktop client instead of a web client as a desktop client supports audio/video redirection on Azure Virtual Desktop.
Windows Desktop clients
Web clients
Android clients
macOS clients
iOS clients
Linux or thin clients
Domain-joined user device (automated deployment): SCCM can be used to push the Azure Virtual Desktop client on the end-user device, or the client can be published in the software center so that authorized users can deploy it on their devices/laptops. Alternatively, AD Group Policy can be used to deploy the Azure Virtual Desktop client on an end user’s laptop using a logon script, and Group Policy can be assigned to the security group created for each host pool.
Nondomain-joined user device (automated deployment): An appropriate Azure Virtual Desktop client can be downloaded from a Microsoft site/other app store and installed on the user laptop/device manually.
Plan for User Profiles
A user profile is an important factor that needs to be considered during pooled Azure Virtual Desktop planning and designing. As we know by now, the pooled version is nonpersistent, and the Azure Virtual Desktop load balancer can send the session to any of the back-end session hosts on the pooled host pool. In this case, the user profile needs to be available on all session hosts so that the user will get the same desktop/settings at every login, and that can be done using FSLogix. FSLogix allows you to store user profiles on the storage account so that FSLogix can attach the user profile to the VM where the user session is redirected by Azure Virtual Desktop.
FSLogix needs to be configured on all session hosts in the host pool, pointing to the same storage account where user profiles are stored. It is recommended to use a premium storage account for each host pool in each region. Storage account support failover so that the user profile data can be fail over to DR region in case of disaster recovery.
You need a separate virtual network with dedicated subnets for each host pool (pooled and personal) in each region, and you need to peer AVD vnet with hub virtual network in that region.
You need a dedicated user profile storage for each pooled host pool.
User profile storage access is restricted to a specific virtual network/subnet.
Enable storage account access over a private endpoint from the virtual network.
The same type of host pool in the same region (i.e. belongs to the same Business Unit) can use the same storage account for a user profile as far as there is no compliance/information security requirements.
The storage account needs to join to the domain and allow specific users/groups to access the content.
Consider GEO replication to a DR region if you are planning to enable disaster recovery for the pooled host pool. Premium file storage does not support GEO replication, so if you want to implement DR, then you must select the standard storage account tier or use an FSLogix cloud cache to store a user profile on multiple storage accounts in different regions.
Storage Tier Recommendations
Workload Type | Recommended File Tier |
---|---|
Light (fewer than 200 users) | Standard file shares |
Light (more than 200 users) | Premium file shares or standard with multiple file shares |
Medium | Premium file shares |
Heavy | Premium file shares |
Power | Premium file shares |
Recommended Solution for Network Connectivity
Azure networking products and services support a wide variety of networking capabilities, so it is important to correctly identify the network requirements for your Azure Virtual Desktop deployment. How you structure these services and the networking architectures you choose depend on your organization’s workload, governance, and connectivity requirements.
How many IP addresses do you need in your virtual network (based on the size of Azure Virtual Desktop virtual network)?
Will your workloads require connectivity between virtual networks and your on-premises datacenter?
Will you need to inspect and audit outgoing traffic by using on-premises network devices?
Do you need multiple virtual networks?
Do you need to connect multiple virtual networks?
Will you need custom DNS and a domain join?
Yes, Azure Virtual Desktop supports domain join for session hosts so that you can apply an organization-specific compliance policy to the session host. AVD virtual network DNS settings can be changed to custom DNS and can point it to organization-specific DNS server so that it can help to resolve Active Directory domain names and join the session host to the domain.
Plannig Azure AD Connect for User Identities
Azure Virtual Desktop supports desktop authentication with Active Directory Domain Services. The AD DS directory can be synchronized with Azure AD to enable it to authenticate on-premises users.
There are two levels of authentications for Azure Virtual Desktop, one at the Azure Virtual Desktop access level and another at desktop login. The Azure Virtual Desktop session host can join to the AD domain, and domain credentials can be used to log in to the desktop, whereas Azure Virtual Desktop authentication can be done by Azure AD, but AD DS needs to be synced with Azure AD if you want to use same credentials for both logins.
Azure AD domain services (AAD DS) and Active Directory Domain Services (AD DS) are two different services.
There are two different AD DS options available and supported by Azure Virtual Desktop. You can select the appropriate AD DS solution based on your organization requirements.
Identity Design Considerations
Azure Virtual Desktop users must be sourced from either the same instance of on-premises Active Directory Domain Services that is synchronized to Azure Active Directory (Azure AD) and the session host needs to be joined to same Active Directory Domain Services (AD DS), or an instance of Azure AD Domain Services (Azure AD DS) synchronized from Azure AD.
Azure Virtual Desktop does not support business-to-business or Microsoft accounts.
A domain join account can’t have multifactor authentication or interactive prompts, and it needs permission on the ADDS OU to add a computer account.
Azure Virtual Desktop supports AD DS or Azure AD DS, and an appropriate identity provider needs to be selected based on the application requirement.
When joining to an Azure AD DS domain, the account must be part of the Azure AD DC administrators’ group, and the account password must work in Azure AD DS.
- Azure AD DS (AAD DS) is a supported option, but there are limitations:
You must have password hash synchronization enabled (uncommon when federating Azure AD).
You can project Azure AD DS into only a single virtual network (and single Azure region) that uses a nonpublic IP address range. You can’t add domain controllers to an Azure AD DS domain.
You cannot use a hybrid join for Azure Virtual Desktop VMs to enable Azure Active Directory seamless single sign-on for Microsoft 365 services.
Always specify an organizational unit distinguished name (DN) for domain joining without quotation marks.
The user principal name used to subscribe to Azure Virtual Desktop must exist in the Active Directory domain where the session host virtual machine is joined.
Smart cards and Windows Hello authentication need a direct connection (line of sight) with an Active Directory domain controller for Kerberos.
Using Windows Hello for Business requires the hybrid certificate trust model to be compatible with Azure Virtual Desktop.
Single sign-on can improve user experience, but it requires additional configuration and is supported only using Active Directory Federation Services.
Identity Design Recommendations
Use Azure AD Connect to synchronize all identities to a single Azure AD tenant.
Ensure Azure Virtual Desktop session hosts can communicate with Azure AD DS or AD DS.
Use the least privilege principle to assign the minimum permissions needed for authorized tasks.
Segregate session host virtual machines into Active Directory organization units for each host pool to manage policies and orphaned objects more easily.
Use a solution like Local Administrator Password Solution (LAPS) to rotate local administrator passwords on Azure Virtual Desktop session hosts frequently.
Create conditional access policies for Azure Virtual Desktop. Such policies can enforce multifactor authentication based on conditions such as risky sign-ins to increase an organization’s security posture.
Configure AD FS to enable single sign-on for users on the corporate network.
Different Directory Options
There are three common ways to use Active Directory–based services in Azure for identity and authentication. This choice of identity solutions is dependent on your organization’s needs. For example, if you have cloud-based application and cloud-only users accessing the application, then Azure Active Directory is a suitable solution, but in case you want to assign a policy on cloud-only devices and you don’t have on-premises AD DS, then you can select Azure Active Directory domain services (AAD DS) . Another use case is if you already have traditional on-premises AD DS and you want to use same domain user to authenticate cloud-based application/devices, then you can sync on-premises AD DS with Azure AD and use the on-premises identity for cloud as well.
Although the three Active Directory–based identity solutions share a common name and technology, they are designed to provide different customer needs.
Active Directory Domain Services (AD DS) : This is a traditional Lightweight Directory Access Protocol (LDAP) server that provides key features such as identity and authentication, computer object management, Group Policy, and trusts. AD DS is a service available in Windows Server, and many organizations are already using it as the central component in their on-premises datacenter. Azure Virtual Desktop supports an on-premises ADDS service, and you can either directly sync on-premises AD DS with Azure AD or extend it in Azure and then sync it with Azure AD to avoid authentication and sync traffic going over VPN/ER. Extended AD DS server in Azure can be used for domain joins and AVD desktop authentication as well.
Azure Active Directory (Azure AD): Azure AD is a cloud-based identity and mobile device management (MDM) provider that gives the ability to create user account and authenticate services for resources such as Microsoft 365, the Azure portal, and software-as-a-service applications. On-premises AD DS can be synchronized with Azure AD to provide a single-user identity across the organization. Azure AD is required for authentication, but it needs to be synced with on-premises AD DS or Azure AD DS.
Azure Active Directory Domain Services (Azure AD DS): Azure AD DS consists of managed domain services the same as traditional AD DS with features such as domain joins, Group Policy, LDAP, and Kerberos/NTLM authentication with a minimal amount of administrative overhead (but limited admin permission; refer to Azure AD DS). Azure AD DS integrates with Azure AD, which itself can synchronize with an on-premises AD DS. This ability extends central identity use cases. Azure AD DS is one of the best options supported by Azure Virtual Desktop if you don’t have any directory solution in place or if you want to set up isolated AVD POC.
Differences Between Azure AD DS and Self-Managed AD DS
Managed domain (Azure AD DS): Microsoft manages the required resources for Azure AD DS, and you can still use all the traditional AD DS features such as domain joins, Group Policy, LDAP, and Kerberos/NTLM authentication. You don’t deploy, manage, patch, and secure the Azure AD DS infrastructure for components such as Windows Server OS or domain controller (DC) VMs. See Figure 3-3.
A self-managed domain (AD DS service on VM): You can create and configure traditional AD DS on Azure virtual machines (VMs) with Windows Server guest OS, and you can use Active Directory Domain Services (AD DS) to extend your on-premises AD DS to the cloud or use on-premises AD DS as is for cloud as well. There’s additional maintenance overhead with a self-managed AD DS environment, but you have ability to do additional tasks such as extend the schema or create forest trusts. See Figure 3-4.
Stand-alone cloud-only AD DS: This option is mostly used when you don’t have on-premises AD DS and just want to create new self-managed AD DS for the Azure cloud. Azure VMs can be configured as domain controllers to create a cloud-only AD DS environment.
Resource forest deployment: This option is mostly used when you have an on-premises AD DS forest and just want to create a new AD DS domain in an existing on-premises forest for the Azure cloud. Azure VMs can be configured as domain controllers and AD DS domains as part of the existing on-premises forest. A trust relationship is then configured to an on-premises AD DS environment so that other Azure VMs can domain-join to this resource forest in the cloud. User authentication runs over a VPN/ExpressRoute connection to the on-premises AD DS environment.
Extend on-premises domain to Azure: This option is mostly used when you have an on-premises AD DS domain and forest and just want to add a cloud-based domain controller in an existing on-premises domain. An Azure virtual network needs to be connected to an on-premises network using a VPN/ExpressRoute connection for this model as well. Azure VMs connect to this Azure virtual network, which lets them domain-join to the on-premises AD DS environment.
Differences Between a Managed Azure AD DS Domain and a Self-Managed AD DS Domain
Feature | Azure AD DS | Self-Managed AD DS |
---|---|---|
Managed service | yes | No |
DNS server | Yes (managed service) | Yes |
Domain or enterprise administrator privileges | No | Yes |
Domain join | Yes | Yes |
Domain authentication using NTLM and Kerberos | Yes | Yes |
Kerberos constrained delegation | Resource-based | Resource-based and account-based |
Custom OU structure | Yes | Yes |
Group Policy | Yes | Yes |
Schema extensions | No | Yes |
AD domain/forest trusts | Yes (one-way outbound forest trusts only) | Yes |
Secure LDAP (LDAPS) | Yes | Yes |
LDAP read | Yes | Yes |
LDAP write | Yes (within the managed domain) | Yes |
Geodistributed deployments | Yes | Yes |
What Is the Best Identity Solution for Azure Virtual Desktop?
Azure Virtual Desktop uses the AD DS domain join feature for all session hosts, and the user must enter domain credentials to log in to Azure Virtual Desktop. To avoid a dependency on site-to-site VPN/ER for authentication traffic to on-premises AD DS, on-premises AD DS can be extended to the Azure hub subscription by creating a domain controller VM in Azure. Most organizations do not want to store password hashes in the cloud AD and prefer to go with pass-through authentication with on-premises AD. This approach increases traffic and dependency on the site-to-site VPN tunnel by sending all authentication/DNS traffic to the on-prem AD. Extending the AD domain controller to Azure is the recommended option if all application/services are using on-premises AD for authentication or else the Azure AD connect VM can be placed on-premises to sync on-premises AD users directly to Azure AD if you have fewer users using cloud services.
All domain controller replication traffic flows over a site-to-site VPN/ER.
A cloud-extended domain controller can be used for authentication instead of sending traffic on-premises when using pass-through authentication.
By default, the Azure AD Connect sync server configures password hash synchronization between the on-premises domain and Azure AD, and the Azure AD service assumes that users authenticate by providing the same password that they use on-premises. The security policy of organization may prohibit synchronizing password hashes to the cloud. In this case, your organization should consider pass-through authentication.
Azure AD tenant: An instance of Azure AD created by organization. It acts as a directory service for cloud applications by storing objects copied from the on-premises Active Directory and provides identity services.
On-premises AD DS server: An on-premises directory and identity service. The AD DS directory can be synchronized with Azure AD to enable it to authenticate on-premises users.
Azure AD Connect sync server: A computer that runs the Azure AD Connect sync service. This service synchronizes information held in the on-premises Active Directory to Azure AD. For example, if you provision or deprovision groups and users on-premises, these changes propagate to Azure AD.
User authentication: By default, the Azure AD Connect sync server configures password hash synchronization between the on-premises domain and Azure AD, and the Azure AD service assumes that users authenticate by providing the same password that they use on-premises. For many organizations, this is appropriate, but if your organization’s security policy prohibits synchronizing password hashes to the cloud, then you should consider pass-through authentication. Alternatively, you can configure Azure AD to use Active Directory Federation Services (AD FS) or a third-party federation provider to implement authentication and SSO rather than by using the password information held in the cloud.
Summary
In this chapter, you learned about Azure Virtual Desktop licensing options, storage options for the session host, and user profile and authentication for AVD.
It is important to know all the options for identity and profiles so that you can design the Azure Virtual Desktop architecture accordingly and select the best options for your enterprise.