Azure Virtual Desktop without Active Directory:
how it works and when it makes sense

In short: with Microsoft Entra Kerberos, Azure Virtual Desktop (AVD) and FSLogix profiles on Azure Files can run without a domain controller: it is still Kerberos, but the tickets are issued by the cloud rather than by Active Directory. For new or «cloud-only» scenarios it is a genuine simplification; for those with domain applications (line-of-business apps, SQL Server) it does not mean «goodbye domain controllers», but a hybrid modernisation. Let’s see how it really works and — above all — when it makes sense.

From the desktop anchored to Active Directory to the cloud

Azure Virtual Desktop was born as an evolution of Remote Desktop Services: first «Windows Virtual Desktop», today a mature platform for delivering desktops and applications as a service. In the early implementations, however, it still required Active Directory Domain Services (AD DS): domain controllers on virtual machines, or the on-premise domain extended to the cloud via VPN or ExpressRoute.

Microsoft is reducing this dependency: with session hosts joined to Microsoft Entra ID and with Entra Kerberos, you can reach the point of no longer needing the domain controller. A useful clarification: the typical AVD session host is Windows 11 Enterprise multi-session — a client OS that accepts multiple concurrent users, the modern heir of the RDSH role on Windows Server (which nonetheless remains supported).

The traditional model: two identities working together

In the classic (hybrid) model two identity systems work together: Microsoft Entra ID manages access to the AVD service, while Active Directory manages Windows authentication and access to the profile. Behind a single sign-on experience, this is what happens:

• 1The user opens the AVD client and authenticates against Entra ID (password, MFA, Windows Hello).
• 2The service assigns a session host and establishes the session on the machine.
• 3To access Windows resources, the machine obtains a Kerberos ticket from the domain controller.
• 4FSLogix uses that ticket to mount the user profile on an SMB share. Everything revolves around the domain controller: FSLogix → SMB → Kerberos → domain controller.

Entra Kerberos: the same Kerberos, without a domain controller

The idea is as simple as it is effective: keep Kerberos, remove the dependency on the domain controller. Microsoft Entra ID becomes the authority able to issue Kerberos tickets to access SMB resources such as Azure Files. The protocol does not change: what changes is who issues the tickets.

In the traditional model every ticket originates from the domain controller, in a realm tied to the Active Directory domain (e.g. company.local). With Entra Kerberos a realm in the cloud is created — KERBEROS.MICROSOFTONLINE.COM — and the KDC is reachable over the internet. You can see this with klist: the ticket does not come from a domain controller, but from a Kerberos authority managed in the cloud. Entra-joined session hosts no longer need line of sight to a DC, and the model works both with hybrid identities (synchronised from AD) and cloud-only ones.

Authentication is not authorisation: RBAC and NTFS ACLs

Once the user is authenticated, how is access to the data authorised? Azure Files uses two layers that work in sequence:

• Share level — Azure RBAC. First of all you check who can access the share and at what level (for example Storage File Data SMB Share Reader or Contributor). It is best to disable the default permissions and assign granular access to dedicated groups.
• File and folder level — NTFS ACLs. Once the RBAC check is passed, the classic Windows permissions apply. Here the Kerberos ticket becomes central again: beyond proving the identity, it carries the user’s SIDs, so Azure Files evaluates the ACLs exactly as an Active Directory environment would. For cloud-only identities the recommended configuration is the Manage access pane.

Cloud-native management: Intune instead of GPOs

Without a domain there are no Group Policies: Entra-joined session hosts are governed with Microsoft Intune. That is where you enable the retrieval of the cloud Kerberos ticket (the CloudKerberosTicketRetrievalEnabled setting, via Settings Catalog) and where you deploy the FSLogix policies that used to go through GPOs.

A point that greatly lowers the barrier to entry: FSLogix is the same agent you already use on Windows Server or RDSH. Only the storage (from a file server to Azure Files) and the source of the tickets (from domain controller to Entra Kerberos) change, along with the deployment tool (from GPO to Intune). The concepts of profile container, redirections and exclusions remain identical: whoever already manages FSLogix does not start from scratch.

Does your company really need it? When it makes sense (and when it is just a fad)

Here is the point that is often missing: «without a domain controller» is not a universal upgrade. The cloud-only model (zero DC) really pays off only in specific scenarios, all sharing the absence of domain applications:

• Greenfield — new companies or branches, born in the cloud, with no on-premise legacy.
• SaaS-only / frontline workers — those who live on Microsoft 365, an AVD desktop and a share, with no legacy line-of-business apps.
• External / B2B identities — cloud-only is the only model that supports them with FSLogix.
• Isolated environments — a project, a DMZ or a perimeter you want kept separate from your Active Directory, in a zero trust perspective.

If, instead, the company has domain-member applications — a line-of-business app, SQL Server in Windows authentication, a domain file server — those systems keep the domain controllers alive. For them the right move is not to chase the «no DC» goal, but a hybrid modernisation: Entra-joined session hosts, Entra Kerberos and FSLogix on Azure Files for the desktop layer, around a slimmed-down Active Directory core:

• RD Gateway → ZTNA. Instead of an RDP gateway exposed on the internet, a Zero Trust Network Access approach that publishes the single resource per-user, verifying identity and device, without exposing anything.
• NPS for MFA → Conditional Access. MFA moves to Entra ID, which evaluates identity, device and risk, instead of a «blind» MFA via RADIUS.
• GPO → Intune. Progressive migration of policies towards Intune, leaving in AD only what the domain servers really need.

There are also some pitfalls to know before you start: each storage account accepts only one identity source (you cannot mix AD DS and Entra Kerberos); with hybrid identities, the share ACLs must be set from a machine that can see the domain controller (the session hosts cannot), and both users and groups must be synchronised to Entra ID; for cloud-only identities you need cloud group enablement (a limit of 1,010 SIDs per ticket) and the disabling of MFA on the storage account app, with availability still limited to some regions. Finally, the Kerberos hardening of April 2026 (from RC4 to AES) can break FSLogix profiles on outdated SMB: it is worth getting aligned first, as we explain in the article on the end of RC4 encryption in Kerberos.

How AtWorkStudio helps

We always start from an audit of Active Directory dependencies before promising simplifications: what really hooks into the domain (line-of-business apps, SQL Server, GPOs, gateways, MFA) and what can be moved. From there we design the right path — AVD desktops, hybrid identity, digital identity management with Entra ID, Intune, Conditional Access and zero trust access — consistent with the requirements of NIS2 and ISO/IEC 27001 best practices. No style exercises: only what brings value.

We have been operating from Piacenza since 2000. We hold ISO/IEC 27001, 27017, 27018 and ISO 9001 certifications, with ACN qualification for cloud services, and we are members of Clusit (Italian Association for Information Security) and affiliated with Confindustria Piacenza in the RICT cluster.