Disabling inter-machine Windows authentication
Posted by devbydemi@reddit | sysadmin | View on Reddit | 44 comments
I’m trying to deal with a situation where it’s likely impossible to run sysprep before cloning. The workflow is too complex to reasonably integrate with the virtualization system in use.
This situation also has no need for integrated Windows authentication. Ideally, all Windows credentials would be rotated at every boot and all Windows authentication would fail.
Is there a way to prevent a machine from ever being able to know that a clone of it exists? None of these machines will ever be joined to AD or Entra.
The reasons sysprep can’t work are numerous:
- There is a limit on how many times one can sysprep an image.
- Booting into Audit Mode is going to be very confusing.
- The need to use Windows PE to capture an image is going to require a lot of nightmarish scripting to automate.
- The entire workflow is based on VM images and just works for Linux VMs, which are most of them, so long as no servers are being run in the VMs.
(In case anyone recognizes the project in question, please note that I am not speaking officially for it.)
Itsquantium@reddit
Backup the clone VHDX and create your own VM then sysprep that version. Then capture the .wim from the VHDX file. Sysprep can be used up to 1k times per image, but if you capture a new. Wim and install it on a new VM, then you'll essentially have unlimited syspreps. You don't need to boot into audit mode. Just ensure default profile is good by using an unattended.xml with copy profile flag in the. Xml file.
devbydemi@reddit (OP)
This isn't a Hyper-V environment, and the updated image isn't used to create a new installation of Windows. Rather, the same installation is being used with with different volumes that store user profiles.
Itsquantium@reddit
Okay I read your update on your post. It sounds like you're looking for a free version of a RDS farm with non persistent VM's and you want to retain user profiles?
What exactly is your end goal? You want to have multiple VM's of the same machine but want all profiles to be connected? What are you trying to accomplish? Why does this process need to be understood by users? Can't you document it with steps so they can accomplish whatever needs to be done? I'm so confused.
devbydemi@reddit (OP)
The system stores the system volume (for Linux, where the root filesystem would be) on one block device. There are multiple VMs based on a given base ("template") VM. Changes to the template VM's root device persist across VM reboots, but changes to the root device of the VMs based on it do not persist across reboots.
This allows maintaining the OS and installed software in only one place, while still allowing the VMs based on a template to be isolated from each other.
This works well for Linux VMs because what needs to be on the root volume and private volume is well-known. If extra stuff from the root volume needs to be on the private volume, this can be handled with bind mounts. For Windows VMs, this works well in practice, but there are corner cases like the one I am trying to address here, or at least understand. My hope is that professional sysadmins (and possibly someone like /u/SteveSyfuhs) would have an idea what to do.
If nothing else, it would be useful to document what should be avoided, such as allowing inbound network connections to certain ports. By default, no such connections are allowed, and this is enforced by a firewall outside of the VM.
Login is not handled by RDS, but rather by an agent that communicates with the VM host.
Presumably joining one of these machines to Active Directory or Entra would be completely broken, unless the template was joined and the VMs based on it had no network access. But that's not a common use-case here.
The actual virtualization platform is Qubes OS, which I used to work on for a living but am no longer affiliated with.
Itsquantium@reddit
Okay I get it now I know exactly what's wrong I think. Are you used to managing windows computers? Are you a dev? I would assume so since you're worked on an OS and you're probably used to using Linux to the point of asking sysadmins for help on windows.
You're looking to create 5(might not be 5, but it's more than 5, or is it 1?) of these windows machines and want to JUST update the template and push that template while all the user information is untouched. Each user would login or RDP to that VM and use that VM's software and store their data there. You are just looking to "clone" 1 windows machine to spread them out to other users, they'll login with the software and store their files there individually? Grouply? And when you need to push updates or something new, you'd want to use the same template as before, and just auto push it out so it only updates the OS and doesn't touch the users data? Tell me if I'm missing something or explain it to me more because I think If I'm thinking what I'm thinking, you might be able to do it, but you'll have to set it up for the users to maintain it, but it could be automated with some GUI vibe code from chat GPT or some shit.
devbydemi@reddit (OP)
Yes, I'm a dev, and no, I'm not used to Windows at all.
The number of VMs based on a template is potentially very large. There's no remote management or push involved. Updates are handled by the user manually logging into the template. The (single) user is given access by an agent installed in the VM which communicates with the host.
There's no authentication involved. The user controls the hypervisor, so they have privileges way beyond what a mere guest administrator does.
The existing code is https://github.com/QubesOS/qubes-core-agent-windows and https://github.com/QubesoS/qubes-gui-agent-windows. It works fine and I'm not particularly interested in changing it myself. What I'm mostly interested in is what will go wrong with this setup, and what would need to be changed to avoid it.
Itsquantium@reddit
I'm still missing pieces, but it's because you're lacking information about windows and the system administration side. No offense to you. I couldn't tell you how to code at all, so if you can change it if you wanted to it shows you're pretty smart. So sorry if I'm asking questions I just need to see the whole picture so I can understand what you're wanting it to do. You're explaining it well on the unix side, which is what made me understand a little bit better to pin point what you actually want.
You're just looking to copy and paste like a shit ton of windows VM's based on a template. When you say updates are made by the user manually logging on to the template, what does that mean? Does it mean they logon and update the VM itself? Or do they login and it pulls from an updated template that was maintained or updated a 2nd or 3rd time by you or someone else because of system updates, etc? You're using that (forgot name) Linux OS as a hyper visor?
So that hyper visor you use right now allows you to set a "template" where other people can login to their Linux machine currently right? Like people are already logging into a Linux based template you created with a couple VM's?
devbydemi@reddit (OP)
No offense taken. Thanks for asking questions and trying to be helpful.
The user directly logs into the template. There's no professional sysadmin involved, nor is there any form of remote management. I figured that sysadmins would know better than anyone else, which is why I asked here.
Most VMs (including all the ones included in the default install) are either templates or based on a template.
I'm not responsible for creating any of these. I'm just trying to figure out what (if anything) is likely to go wrong, and how to avoid that going wrong.
Itsquantium@reddit
So I think we might have 2 different definitions of a template. What does a template mean? Is it an already created virtualized machine? Or is it something that sits until you "copy" it and make it into production? You're just looking for an easy way to push a certain number of virtual machines out via a golden image the easiest way possible and easy way for non technical users to do it?
You're not responsible for creating what? A template? A VM? Making 20 VM's for 20 users where they login with the same credentials?
You asked what is likely to go wrong? That depends on your next comment to me with more information. I just need to understand what is IT supposed to do and what is IT not doing. You have this working already on unix right? You're just asking I'm regards to how windows would work this way?
devbydemi@reddit (OP)
There's no IT department involved. I'd ask on /r/homelab or similar except I don't think they would be able to provide a decent answer.
A template is an already created VM. The volume containing the OS is used to boot the VMs based on it. These VMs get a throwaway snapshot of it.
I'm looking to document what can and will go wrong with the current setup, under what circumstances that happens, and what changes could be made to mitigate that.
There are no credentials involved. Login is automatic with no password required. The account password is randomized at startup, though ideally it would not even exist.
Itsquantium@reddit
Hahahah I mean IT not information Technology. I mean the word "it". It as in, it was a guy.
So your current set up or process right now for windows is what? Copy the virtual machine? Set up auto login for user? Because if this isn't touching a domain, or wont touch the internet, there would be issues with licenses unless the template was syspreped before deploying a new template. If licenseing isn't an issue then, which it should be, then this doesn't matter anyways. duplicate SIDS won't matter.
devbydemi@reddit (OP)
The current processes is to install Windows using the OEM license of host computer and the publicly available install ISO. The guest agent is added automation, which also sets up autologin. It's all scripted.
VMs based on the template reuse its root volume (without changes) but not its private volume. I believe there is typically only one Windows template on a system.
Itsquantium@reddit
So what you're wanting is a differencing disk or a parent child disk. That's what it's called on windows Hyper-V, at least. Where you have your parent disk and you create multiple child disks, which they store their own shit in child, but the parent is the original OS. each child is different, but shares from the same parent. If that's your current process for windows installation, what are you asking? How to improve it? Make it easy for end users to do it?
Because I'm pretty sure you're describing a windows hyper V differencing disk with a child parent relationship?
devbydemi@reddit (OP)
Not quite. I presume that a differencing disk is fully writeable, meaning that both the parent and child must be updated. In this case, all updates happen in the parent. Updates to the child's root volume are discarded after the child shuts down.
That's the magic of the system, and is what allows managing 10 systems while only having to update 1.
Itsquantium@reddit
Cool. Then what you're looking for is windows RDS. You can create VM's with a syspreped template. It automatically pushes it out to every VDI client to your VDI server. You would need a domain though. As far as I know, there's not a way to do this natively on windows other than RDS VDI set up for non persistence. There is no other way to do it other than RDS unfortunately unless there's a 3rd party tool.
devbydemi@reddit (OP)
Qubes OS uses its own tools for this, but it doesn't use sysprep and doing so would be quite intrusive. Neither does Omnessia for that matter, though Omnessia offers it as an option.
Is this going to cause any sort of problems, provided that inbound connections to the VMs aren't allowed?
Itsquantium@reddit
If the qubes OS handles it just fine, then It won't be an issue unless these machines ever need to talk to one another or if you are audited due to licenseing. If you ever wanted machines to be on a domain, this way of handling windows clinets this way would not work for the real world.
Itsquantium@reddit
You can still pull the .wim out of whatever environment your running a virtualized windows machine on. Then the only way you can do that would be for you to
Create a copy of it or do the equivalent of a checkpoint or what ever VMware, horizon, or whatever environment you manage the VM's on.
Pull the .wim of that copy.
Then create a bootable installer windows image with the .wim (MDT or SCCM)
I'm super confused as to what you're wanting to do, and it might be because you want to stay anonymous. Can you be more specific in your environment as to how your environment works and what exactly are you looking for to an alternative sysprep and capture the windows image and wanting live profile migration to it? Because there's better ways to handle profiles, like roaming profiles or setting profiles to store to a data on a file server.
devbydemi@reddit (OP)
/r/sysadmin/comments/1t29i0r/disabling_intermachine_windows_authentication/ojr0a1h/ has the details.
I'm not trying to stay anonymous, but I used to work on Qubes OS and am well-known in that community. So I wanted to avoid anyone thinking that I am speaking in an official capacity. In fact, I'm no longer affiliated with the project, though I'm still a user.
It's very different than what one would expect in an enterprise environment. If nothing else, I want to at least understand what will go wrong.
canadian_sysadmin@reddit
Don't [continuously] sysprep the golden image / VM...? Why are you sysprepping it? (yes I understand fully what sysprep does)
Normally your golden image stays un-sysprepped. Once you're ready to deploy, you snap and sysprep, leaving the golden master VM/image un-sysprepped.
Any further updates or iterations are from the original, not the sysprepped original.
I've deployed a fair number of VDI/AVD infrastructure and never ran into this. Maybe I'm missing something, but normally you leave the original golden un-sysprepped. I'm not overly involved in this anymore but our AVD root images I know are unsysprepped. We update them monthly and the resulting client image has only ever seen a sysprep once.
Itsquantium@reddit
You don't need to leave the gold image un syspreped. It's probably good practice, but I do a new sysprep once a year for licenses for apps on our VDI gold image. I ain't ever hitting the 1k limit because I'll just rebuild it once new windows gets released. Before windows 10, the limit was 3 times. They upped it. If you hit the 1k limit of sysprep that's insane hahaha.
canadian_sysadmin@reddit
But you probably should. There's no value-add to sysprepping before the snap/clone workflow. That means any time you need to make a change, you're working on a newly generalized machine, which could have other negative effects (which I've seen - some apps really only like being sysprepped over and over).
Itsquantium@reddit
Maybe back then. On windows 11, it's solid. Some apps do break with sysprep though, which are fixable with post scripts. I've seen a whole lot of weird behaviors that aren't expected, but even if my OS gets corrupted, I would just use a backup. This ain't the old days
crankysysadmin@reddit
I guarantee this is an XY problem.
devbydemi@reddit (OP)
See edit: it somewhat is, but I’ve yet to see any other path for a solution.
crankysysadmin@reddit
the problem is that you're using an ancient workflow that makes no sense. nobody does monolithic imaging anymore and maintains images over time and keeps wanting to fork them. you should be building fresh images from a recipe using a config management tool, not keeping an image around indefinitely and trying to branch off of it forever.
usually if someone thinks they have super unique needs that break how an OS works, the problem is not the OS
devbydemi@reddit (OP)
In this case, the "super unique needs" are:
crankysysadmin@reddit
why?
devbydemi@reddit (OP)
Skylis@reddit
Your business model is not required to be viable
devbydemi@reddit (OP)
It's a system that is already in use. So yes, it is viable. I am mostly wondering what the caveats are.
See /r/sysadmin/comments/1t29i0r/disabling_intermachine_windows_authentication/ojr0a1h/ and the "Additional constraints" section of the edited post for details.
theoriginalharbinger@reddit
Probably oughta tell us what the "virtualization system in use" is.
Because this is easily solvable with VMware templating and VMware API's. Likely also doable with Hyper-V PowerShell command set.
Like, this is not an "ancient workflow" problem. This is almost certainly a lack of awareness of tools you have available to you.
devbydemi@reddit (OP)
I'd rather not name the virtualization system because I used to work on it for a living, and I want to avoid any impression that I am speaking officially on behalf of the project.
Please see the "Additional constraints" section of the edited post for details.
Ssakaa@reddit
Not really all that numerous...
Build in a VM. Snapshot. Sysprep. Capture. Revert. You can do this as many times as you want. And that's the lazy option. More importantly, RTFM.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd744512(v=ws.10)
... wow. r/shittysysadmin is over thataway. If doing your job is confusing, especially when it's that minimal, well documented, step? Maybe IT isn't for you?
You say that like it's not all, already, built and working automation. Seriously. This isn't new, it's not all that complex. You shouldn't be reinventing a wheel here. And introducing unsupported post-image changes to avoid the supported image build/capture workflow is a whole other realm of nightmarish hacks.
That's a complete sidestep.... and has absolutely nothing to do with the image build process... other than exposing that you are working in an environment with virtualization, so... "build your image in a vm so you can snapshot before the sysprep" not being your first idea is even more baffling.
Oh. It's worse. It's so much worse. Snapshot. Seriously. One simple button. And if you're using virtualization, you DON'T EVEN NEED TO CAPTURE AN IMAGE. You just snapshot, sysprep, clone that off as a static golden template, then revert the snapshot on the build vm. Why in the nine hells would you make it tens of times more complicated than that?
devbydemi@reddit (OP)
The system is intended to be used by non-technical users, for whom audit mode would be confusing. See the additional constraints section of the edited post.
mahsab@reddit
Um, just clone and that's it? Zero issues with that in non-AD environment.
devbydemi@reddit (OP)
That's what is done right now. I want to avoid future footguns.
Entegy@reddit
Yes hello I hate my life and create abominations of installs, but I will blame it on Microsoft to make myself feel better.
devbydemi@reddit (OP)
Making it difficult to clone a Windows installation arguably is Microsoft's fault.
Skylis@reddit
Shitty sysadmin is leaking 😅
devbydemi@reddit (OP)
See edit and the "Additional constraints" section. Not everyone is in a situation where they can follow best practices.
Dave_A480@reddit
Can you use something like FOG that changes the SID after image deployment?
devbydemi@reddit (OP)
These are non-persistent VMs and the changes would be reverted after a reboot.
Mountain-eagle-xray@reddit
There is no possible way youre running up against the system limit.