2025-07-10 - Active Directory 5.0 - Group Policy Foundations: Understanding Domain Admins and User Accounts / Setting up Remote Access

 Why You Use TESTLAB\Administrator Across Multiple Machines — And Why You Need Separate Domain Users

When you join a workstation to an Active Directory domain like testlab.local, you can log into that machine using domain credentials. One of the first accounts I am using is TESTLAB\Administrator — the default domain admin account I created when I promoted my Windows Server to a domain controller.

Here’s what that means:

• One Account, Many Machines: TESTLAB\Administrator is a single domain-wide admin account. I can use it to log into any machine joined to my domain, whether it’s the server or a workstation.

• Local Access with Domain Credentials: Logging into a workstation as TESTLAB\Administrator doesn’t magically give me access to the server from that workstation — it just means I have admin rights on that local machine using the domain account.

• Why Not Use This Account Daily? Because TESTLAB\Administrator has full domain admin powers, it’s risky to use it for everyday tasks. Mistakes or malware on one machine can affect my entire domain.

• Create Separate Domain User Accounts: Instead of using TESTLAB\Administrator for daily work, you create separate domain user accounts (for example TESTLAB\ChristianUser). These accounts have limited permissions tailored for each user.

• Manage Users with Group Policy: By managing domain user accounts, I can apply group policies that control user access, permissions, security settings, and more — keeping my network secure and organized.

• Users Aren’t Per Machine: I don’t create a new user for every workstation. One domain user can log into multiple domain-joined machines based on my permissions and policies.

Bottom line: Using TESTLAB\Administrator across all machines is normal at first. But for security and management, create individual domain user accounts for daily use and control them through Active Directory and Group Policy.

💻 Setting Up Seamless Remote Access to Windows Server VMs on Proxmox Using AnyDesk

In this post, I’ll walk through how I configured remote desktop access to a Windows Server VM running on Proxmox, bypassing the clunky built-in Proxmox console using AnyDesk with unattended access and automatic login.

This setup lets me spin up a VM and connect just using AnyDesk with zero interaction needed on the VM side. It's ideal for test labs and managing multiple VMs for learning and experimentation. This removed a great deal of security because passwords are bypassed as much as possible to make  running this test lab as smooth and not tedious as possible. 

---

🧠 Why I Chose AnyDesk Over Other Options

❌ Proxmox Console: Not Suitable for Daily Use

While Proxmox’s built-in console is fine for initial setup or emergencies, it’s:

• Laggy and unresponsive

• Doesn’t support copy-paste or file transfer

• Poor resolution scaling

• Not good for day-to-day usability

Why I Got Sick of Using the Proxmox Console

I’ve been working more and more on Active Directory over the past few weeks — it’s now my top priority every day. Because of that, I’ve been spending a lot more time inside the Proxmox console, and it’s gotten tedious.

The scaling issues are the first problem. I’ve had to just deal with the copy-paste limitations between the VMs and my laptop, which is where all my actual productivity happens.

To get the scaling just right, I developed this clunky routine:

Maximize the VM console window > In the console sidebar, go full screen > Escape out of full screen > Minimize the sidebar > Restore the window size > resize entire window to suit my needs. 

And I’d have to repeat this entire process for every single VM I am working on at that time. Then if there is a problem, I have to reboot, some error that causes a closure, whatever, I have to go through the process again. If I didn’t, the console would stay zoomed in — I couldn’t see the taskbar or some of the desktop icons, and I’d be stuck scrolling around the desktop, which just slows everything down.

❌ Remote Desktop (RDP): Not an Option Here

RDP is only available on Windows Server with Remote Desktop enabled, or on Pro and Enterprise editions of Windows. My laptop is running Windows Home, which can initiate RDP sessions, but not with machines on a domain without being Pro or Enterprise, and some of my test VMs might not support it either.

❌ RustDesk: Good, but Unnecessary

RustDesk is a great open-source alternative to the Proxmox Console and Remote Desktop — but:

• I'm already familiar with AnyDesk

• It’s already installed and working well on my laptop and other machines I run 

• There's no compelling reason to switch for this workflow

So AnyDesk was the perfect fit: familiar, fast, and cross-platform.

---

🧩 What I Set Up

1. Installed and Configured AnyDesk on the Windows Server VM

• Installed AnyDesk and Right-clicked the AnyDesk shortcut icon > in shortcut tab > Advanced > Chose Run as administrator. (I'm not sure if this was necessary). I spent some time trying to get unattended access to work and doing this was part of what I did to troubleshoot why it wasn't working. 

• Set AnyDesk to start with Windows via:

  • To set AnyDesk to start automatically with Windows, I:

    Opened Task Manager > Went to Startup > Confirmed AnyDesk was enabled

    It was already enabled, but I wasn't sure, since setting up Unattended Access was turned on but not working (I actually did these things in reverse order), I double-checked by:

    Opening the Run dialog (Win + R) > Typed services.msc > Hit Enter to open the Services window

    Searched and clicked on the AnyDesk service to check its' configuration which was set to automatic. 

    I rebooted since that was all that was left to do, and it worked.  

• 🔥 Firewall Rules

  To make sure AnyDesk could connect without issues, I added inbound and outbound rules for both TCP and UDP on the following ports:

  80, 443, 7070, and 6568

  In hindsight I believe that only port 7070 was necessary but since I am only doing this to streamline using the VM's and this will have no bearing on AD itself and I actually really need to get going and finish this project as soon as possible, I will skip this for now. If I had the time, I would disable certain rles one by one to see which ones I can't be without. Instructions online led me to believe all of these were necessary despite my feeling this could potentially open me up to attacks. But I read that some of these ports like 80 for HTTP (which is not a secure protocol, frequently replaced by 443 for HTTPS) has to be opened anyway if you want to browse online. 

  Then I spent time figuring out how to add that file to Proxmox as a virtual CD ISO, so I could mount it inside my other Windows 11 VMs and import the rules directly — no need to recreate them by hand every time.

  • In Settings > Access > Unattended Access, I found no option to simply enable it. I noticed that on this Windows Server install, the Unlock button — normally visible on the Access page on all my other machines — was missing. I thought that might be why I couldn’t turn it on.

    Eventually, I found the workaround:

    Settings > Security > Permissions > Permission Profiles > Selected Unattended Access > Changed the password

    I didn’t want to use a password, but it didn't seem to enable Unattended Access until I added one. 

•   These rules were added manually in Windows Defender Firewall > Advanced Settings on the Windows Server VM — and it was tedious. 

• I didn’t want to manually recreate those rules for every new VM, so I decided to mount it as a virtual CD in other VMs, so I exported the finished firewall configuration as a .wfw file using:

• netsh advfirewall export "C:\AllRules.wfw"

• 
  

• 📂 Adding the Firewall Rules ISO to Proxmox Storage and Attaching to a VM

  
  

  Uploaded it to my file server. 

   I didn’t want to manually recreate those rules for every new VM, so I decided to mount it as a virtual CD in other VMs — using the Proxmox web interface, thinking it would be easier. 

  In Proxmox web UI:
  Datacenter > Add > LVM

  In the window that popped up, I:

  • Named the storage anydeskfirewallrules

  • Set the directory path where I wanted to store the ISO (e.g., /var/lib/vz/template/iso/)

  • Selected Content type: ISO image

  After adding that storage, I clicked on anydeskfirewallrules in the Proxmox tree on the left.

  In the middle pane, I found the ISO Images tab under that storage, clicked it, then clicked the Upload button.

• Found out the hard way I needed to turn the .wfw file into an ISO, downloaded CDBurnerXP and converted it. 
• Opened CDBurnerxp > Selected Data Disc and pressed OK > Dragged and Dropped file in main window > File > Save Compilation as ISO File. Do not select Convert ISO Image!

          I uploaded the firewall rules ISO file I’d saved on my fileserver.

• Next, I went to the target VM:

  • Opened Hardware

  • Selected the CD/DVD drive

  • Changed the ISO to the new firewall rules ISO from anydeskfirewallrules storage

  Finally, I booted into the VM and verified the .wfw file was accessible from the mounted virtual CD-ROM drive.

• Set Unattended Access:

                    And usually where you add a password for Unattended Access is just Settings > Access >                        Unattended Access, and there is a button to set password right there. Maybe I am                                    misremembering, and you set a password right there and then things operate as normal. 

                    But to then deal with the password problem, when accessing the VM through                                        AnyDesk on another machine, simply select to Remember Password. 

2. Enabled Automatic Login to a Domain Admin Account

Used the registry method for forcing auto-login:

In regedit, navigated to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Created/edited the following string values:

Name	Value
AutoAdminLogon	1
DefaultUserName	DOMAIN_NAME\Administrator
DefaultPassword	yourpassword (plaintext)
DefaultDomainName	DOMAIN_NAME

        ⚠️ Password is stored in plaintext. Acceptable for lab use only.

3. Optional: Disabled the Lock Screen

To keep things as frictionless as possible:

Added in regedit:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Personalization

Created a new DWORD:
Name: NoLockScreen
Value: 1

---

🧱 Final Touches

• Confirmed clipboard and file transfer were enabled in AnyDesk permissions

• Saved and exported firewall rules to ISO so I can easily import them into future VMs

• Verified everything works by shutting down and restarting the VM via Proxmox

---

✅ Outcome

Now I can:

• Boot the VM from Proxmox

• Wait a few minutes for Windows to auto-login, so I do still use the console to know when to open AnyDesk connection. 

• Connect instantly via AnyDesk using the ID + password (no prompts, no console)

This avoids all the limitations of the Proxmox console, gets around the lack of RDP support on my local machine, and lets me stick with tools I already use. It’s a fast, smooth remote access experience — perfect for lab environments or learning setups where convenience matters more than enterprise lockdowns.

This has been Truncat3d 00000000111100010100110______________end of line