Is there a supported way to set and read host bind/connect permissions for Hyper-V sockets on VMMS-managed VMs?

Thank you. I would like to follow your recommendation for an authoritative clarification. Which support category or documentation-feedback route should receive this VMMS-specific question? Before escalating, could you clarify whether point 5 establishes Windows-enforced bind/connect exclusion, or only authorization within the broker application? Has the absence of a supported VMMS interface been confirmed by the product team?

Thank you for the thoughtful follow-up questions. I appreciate the care you're taking to distinguish between VMMS-managed VMs and HCS-managed compute systems before committing to an implementation approach. Based on the documentation currently available, I would make the following clarifications.

1. Regarding point 5

My earlier point 5 was intended to describe authorization implemented by a host-side broker or service application. It was not intended to imply that Windows is documented to enforce per-account bind or connect restrictions at the Hyper-V socket layer for VMMS-managed VMs.

For example, a broker running under a restricted service account can authenticate callers, enforce its own access policy, and reject unauthorized requests. That can be an effective application-level security design. However, that is different from Windows enforcing a socket-level security boundary that allows one host account to bind or connect while denying another.

To clarify the intent of that point:

For a VMMS-managed VM, an application can enforce authorization within its own host-side service or broker. However, the documentation reviewed does not establish that Windows performs host-account-specific AF_HYPERV bind or connect authorization for a VM ID and Service ID pair, nor that it prevents other host processes from attempting those operations before the broker is involved.

Therefore, if your requirement is specifically for Windows itself to allow one host service account while denying other host accounts at the Hyper-V socket layer, I was unable to find documentation that confirms such a mechanism for ordinary VMMS-managed virtual machines.

2. Has this been confirmed by the Hyper-V product team?

No. My previous response was based on the publicly available documentation and published management interfaces. It should not be interpreted as a statement from the Hyper-V product team or as confirmation that no undocumented implementation exists.

More specifically, I was unable to find documentation that:

• Maps BindSecurityDescriptor or ConnectSecurityDescriptor to a VM created and managed by VMMS.
• Describes a supported VMMS/WMI property or Hyper-V PowerShell interface for configuring those descriptors.
• Documents a supported method to query effective bind or connect permissions for a VM ID and Service ID pair.
• States that the GuestCommunicationServices registration-key DACL is the authorization mechanism evaluated by AF_HYPERV.
• Identifies supported Windows client or Windows Server versions for such functionality on VMMS-managed VMs.

Because of that, I believe the most accurate characterization is that this is currently an undocumented or unconfirmed area of the VMMS interface, rather than proof that the capability does not exist.

3. Recommended escalation path

If you would like an authoritative answer, I would recommend opening a Microsoft Support case under Windows / Hyper-V and presenting this as a virtualization platform supportability question rather than a VMConnect question.

When opening the case, I would suggest asking Microsoft to explicitly confirm:

• Whether BindSecurityDescriptor and ConnectSecurityDescriptor are supported for persistent VMMS-managed VMs.
• Whether an equivalent VMMS/WMI or PowerShell interface exists.
• Whether the GuestCommunicationServices registry-key permissions participate in AF_HYPERV authorization decisions or are only used to protect registration data.
• Whether Windows performs host-token authorization checks during bind(), connect(), or both.
• Whether effective permissions can be queried through a supported interface.
• Which Windows client and Windows Server versions, if any, support this functionality.

Including the host build number, Windows edition, servicing channel, VM configuration version, and a minimal reproduction scenario will help support engage the correct engineering team more quickly.

4. Documentation feedback

You may also wish to submit documentation feedback through the relevant Microsoft Learn pages, particularly the Hyper-V sockets and integration services documentation.

A useful documentation request would be clarification of:

• Host-side authorization behavior for AF_HYPERV bind and connect operations.
• Whether service-registration permissions affect socket authorization.
• Whether HCS socket security descriptors apply to VMMS-created virtual machines.
• The supported management interface, if any, for configuring or querying effective permissions.
• Applicable version and lifecycle requirements.

Finally, until Microsoft Support or the product team provides guidance, I would be cautious about relying on either the HCS security-descriptor fields or the service-registration key DACL as a supported security boundary for VMMS-managed VMs. Similarly, I would view broker-side authorization as an application-level control rather than documented evidence of Windows-enforced socket-level account isolation.

I hope this helps clarify the distinction and gives you a more direct path to obtaining an authoritative answer from the Hyper-V engineering side.