How to manage Domain Permissions from a Workgroup VM

Question

I have a technical challenge in an isolated (air-gapped) network. I need some advice on how to manage folder permissions.

My Environment:

• Server: Windows Server 2022 (Joined to Domain).

Client: Windows 10/11 Virtual Machines (Workgroup mode, NOT in domain).

Network: The VMs can connect to the File Server, but they CANNOT connect to the Domain Controller (DC).

Login: Users access the folders using their domain accounts (Domain\UserA).

The Problem: User A is the owner of a folder. He wants to add User B (another domain user) to the permissions list.

When he tries to do this from the VM (Right-click Folder > Security > Add), he gets this error:

"Unable to contact Active Directory to access or verify claim types."

Because the VM is not in the domain and cannot see the DC, it fails to find the user list.

My Questions:

• Are there any ways to let "Workgroup Users" manage "Domain Permissions" in an isolated network?

We cannot join these VMs to the domain due to security policy.

Answer 1

Hi KylanWong,

I just wanted to follow up and see if you had a chance to review the administrative workarounds provided above. Did utilizing PowerShell Remoting or setting up a domain-joined RemoteApp help your users successfully manage their folder permissions within the isolated network? Please let me know if you are still facing challenges, or if you need any further assistance or clarification on implementing these approaches.

Answer 2

Hi KylanWong,

The error "Unable to contact Active Directory to access or verify claim types" occurs because the Windows GUI "Object Picker" (the interface you use to search and add users) operates locally on the client machine. It attempts to query the Domain Controller directly via LDAP and RPC to translate the username into a Security Identifier (SID) before applying the permission. Since your Workgroup VM is isolated and cannot reach the DC, this translation process fundamentally breaks.

Because the local GUI relies on direct DC access, you cannot bypass this from the Workgroup VM's visual interface. You must shift the execution context to the File Server (which does have DC access). Here are the two most viable administrative approaches for your isolated environment:

1. PowerShell Remoting (Native & Scriptable)

Your system administrator can add the folder owners (like User A) to the Remote Management Users group on the File Server. This allows User A to open PowerShell on their Workgroup VM and establish a secure remote session directly to the File Server by running: Enter-PSSession -ComputerName <FileServer_IP> -Credential (Get-Credential)

Once connected, the shell runs in the context of the File Server. User A can then seamlessly assign permissions using standard command-line tools, as the File Server can easily contact the DC to resolve the names: icacls "D:\Shares\TargetFolder" /grant "Domain\UserB:(OI)(CI)M"

2. A Domain-Joined Jump Box or RemoteApp (GUI Friendly)

If your users are not comfortable with command-line tools, the most secure and standard enterprise workaround is to deploy a lightweight, domain-joined "Management VM" or RDS server within the secure network zone. You can publish "Windows Explorer" as a RemoteApp. Users on the Workgroup VMs can launch this RemoteApp (authenticating with their domain credentials). Since the application is running on a domain-joined machine, the GUI Object Picker will work perfectly, allowing them to right-click and manage permissions visually as usual.

I hope this answer provided you with useful information. If so, please click "Accept Answer". If you have any questions, do not hesitate to leave a comment.

Tracy Le.

Answer 3

In this topology, workgroup clients that can’t contact a domain controller can’t perform any operation that requires querying Active Directory, including:

• Resolving DOMAIN\UserB from the Security tab (object picker)
• Evaluating AD claims / central access policies

Because the VM isn’t domain-joined and has no DC connectivity, it has no secure channel to the domain and can’t query AD for user or group objects. That’s exactly what the error message reflects.

Given the constraints (air‑gapped, VMs must remain in a workgroup, and no DC connectivity), there’s no supported way for users logged on to those workgroup VMs to directly manage NTFS permissions for other domain users using the standard GUI or object picker.

The workable patterns in this scenario are:

1. Centralize permission management on a domain‑joined system
   • Have a domain‑joined admin workstation or use the file server itself (via RDP or console) to manage ACLs.
   • A user with appropriate rights (e.g., the folder owner or an admin) signs in with a domain account on that domain‑joined machine and uses the Security tab there to add DOMAIN\UserB to the folder permissions.
   • The workgroup VMs then just consume the resulting permissions; they don’t author them.
2. Use domain groups instead of per‑user ACL changes from workgroup clients
   • Create domain security groups (e.g., FileShare_ProjectX_RW).
   • Manage group membership on a domain‑joined machine (or via standard AD tools).
   • Assign permissions on the file server to the group, not to individual users.
   • When User A wants to give User B access, a domain‑joined admin (or delegated owner) adds User B to the appropriate group in AD. No ACL changes are done from the workgroup VM.
3. Delegate AD and file permissions appropriately (but only on domain‑joined systems)
   • If non‑admin users need to manage who can join computers to the domain or manage certain AD objects, use delegation as described in the domain join permissions and delegation guidance, but this still requires domain‑joined systems and DC connectivity. It doesn’t change the limitation for workgroup VMs.

Because the workgroup VMs cannot contact a DC and cannot be joined to the domain, they cannot safely or reliably resolve and assign domain identities in ACLs. All domain ACL management must be done from a domain‑joined machine that has connectivity to a domain controller.

---

References:

• Active Directory domain join permissions
• Error: Access is denied when non-administrator users who have been delegated control try to join computers to a domain
• Troubleshoot password writeback access rights and permissions