Forbid non-standalone Windows VMs from being domain joined

[DemiMarie]

How to file a helpful issue

The problem you're addressing (if any)

Joining a Windows TemplateVM or TemplateBasedVM to an Active Directory domain, or to Azure Active Directory, will never work. The reason is that both of these rely on configuration, including secrets, that must be unique to a given machine. Having two Windows VMs with the same Active Directory machine account is a bad idea; I suspect it has undefined results.

The solution you'd like

Trying to join a non-standalone Windows VM to a domain, or making a domain-joined Windows VM a TemplateVM, should fail.

The value to a user, and who that user might be

Windows users will avoid a not-very-obvious footgun.

[GWeck]

This severely restricts Windows usage if personal data are processed (see Windows 10 and 11 Usage According to GDPR). The GDPR requires that any telemetry is suppressed in this case, but, on the other hand, connection to Windows servers may be required from time to time for license and activation control. This can only be achieved if any personal data are kept in an AppVM with no Internet access, while the connections to the Microsoft servers are made from the corresponding template.

Using a StandaloneVM would expose the personal data to telemetry transmissions, which is, in the EU, forbidden according to the GDPR. The only logical consequence in this dilemma is, in my opinion, never to join a Windows system processing personal data to an Active Directory domain.

But, on the other hand, this situation in Qubes is not worse than using Windows outside of Qubes, because a native Windows system processing personal data cannot be legally used without killing its telemetry - which is not fully possible. At least, Qubes provides a solution for systems without Active Directory.

[marmarek]

Alternative solution could be ensuring all those secrets are stored on private volume, instead of root volume. This will be some challenge and will require substantial knowledge of Windows internals, but in principle should be possible.

BTW, there are several tools for cloning the same Windows installation to multiple machines, but AFAIK all of them require joining an Active Directory domain only after cloning (some performs the join procedure at the end of the clone process).

[DemiMarie]

Alternative solution could be ensuring all those secrets are stored on private volume, instead of root volume. This will be some challenge and will require substantial knowledge of Windows internals, but in principle should be possible.

A good first step would be to ensure this for Linux VMs, which is much easier (just use bind-mounts properly). Then Windows VMs can be looked at.

BTW, there are several tools for cloning the same Windows installation to multiple machines, but AFAIK all of them require joining an Active Directory domain only after cloning (some performs the join procedure at the end of the clone process).

That is what I expected. This is an area where storage deduplication would be a big win, as it means that having a bunch of StandaloneVMs does not waste a massive amount of storage.

[marmarek]

This is an area where storage deduplication would be a big win, as it means that having a bunch of StandaloneVMs does not waste a massive amount of storage.

But then, you'd need each of those StandaloneVMs connect to the internet from time to time (updates, licensing etc), which makes it significantly less useful (data safety if nothing else).

[DemiMarie]

This is an area where storage deduplication would be a big win, as it means that having a bunch of StandaloneVMs does not waste a massive amount of storage.

But then, you'd need each of those StandaloneVMs connect to the internet from time to time (updates, licensing etc), which makes it significantly less useful (data safety if nothing else).

Fair point. I believe Microsoft’s recommendation for this is KMS + WSUS but only enterprises will have that. That said, a domain-joined VM does need to reach its domain controller at least.