Support for deploying Hyper-V extended port ACLs in System Center 2012 R2 VMM with Update Rollup 8

Defining new port ACLs and their port ACL rules

You can now create ACLs and their ACL rules directly from in VMM by using PowerShell cmdlets.

Create a new ACL

The following new PowerShell cmdlets are added:

New-SCPortACL –Name <string> [–Description <string>]

–Name: Name of the port ACL

–Description: Description of the port ACL (optional parameter)

Get-SCPortACL

Retrieves all the port ACLs

–Name: Optionally filter by name

–ID: Optionally filter by ID

Sample commands

New-SCPortACL -Name Samplerule -Description SampleDescription 

$acl = Get-SCPortACL -Name Samplerule 

New PowerShell cmdlets that are added

New-SCPortACLrule -PortACL <PortACL> -Name <string> [-Description <string>] -Type <Inbound | Outbound> -Action <Allow | Deny> -Priority <uint16> -Protocol <Tcp | Udp | Any> [-SourceAddressPrefix <string: IPAddress | IPSubnet>] [-SourcePortRange <string:X|X-Y|Any>] [-DestinationAddressPrefix <string: IPAddress | IPSubnet>] [-DestinationPortRange <string:X|X-Y|Any>]

Get-SCPortACLrule

Retrieves all the port ACL rules.

• Name: Optionally filter by name

• ID: Optionally filter by ID

• PortACL: Optionally filter by port ACL

Sample commands

New-SCPortACLrule -Name AllowSMBIn -Description "Allow inbound TCP Port 445" -Type Inbound -Protocol TCP -Action Allow -PortACL $acl -SourcePortRange 445 -Priority 10 

New-SCPortACLrule -Name AllowSMBOut -Description "Allow outbound TCP Port 445" -Type Outbound -Protocol TCP -Action Allow -PortACL $acl -DestinationPortRange 445 -Priority 10 

New-SCPortACLrule -Name DenyAllIn -Description "All Inbould" -Type Inbound -Protocol Any -Action Deny -PortACL $acl -Priority 20 

New-SCPortACLrule -Name DenyAllOut -Description "All Outbound" -Type Outbound  -Protocol Any -Action Deny -PortACL $acl -Priority 20

Attaching and detaching port ACLs

ACLs can be attached to the following:

• Global settings (Applies to all the VM network adapters. Only full admins can do this.)

• VM network (Full admins/tenant admins/SSUs can do this.)

• VM subnet (Full admins/tenant admins/SSUs can do this.)

• Virtual network adapters (Full admins/tenant admins/SSUs can do this.)

Global settings

These port ACL rules apply to all VM virtual network adapters in the infrastructure.

Existing PowerShell cmdlets were updated with new parameters for attaching and detaching port ACLs.

Set-SCVMMServer –VMMServer <VMMServer> [-PortACL <NetworkAccessControlList> | -RemovePortACL ]

• PortACL: New optional parameter that configures the specified port ACL to global settings.

• RemovePortACL: New optional parameter that removes any configured port ACL from global settings.

Get-SCVMMServer: Returns the configured port ACL in the returned object.

Sample commands

Set-SCVMMServer -VMMServer "VMM.Contoso.Local" -PortACL $acl 

Set-SCVMMServer -VMMServer "VMM.Contoso.Local" -RemovePortACL 

VM network

These rules will be applied to all VM virtual network adapters that are connected to this VM network.

Existing PowerShell cmdlets were updated with new parameters for attaching and detaching port ACLs.

New-SCVMNetwork [–PortACL <NetworkAccessControlList>] [rest of the parameters]

-PortACL: New optional parameter that lets you specify a port ACL to the VM network during creation.

Set-SCVMNetwork [–PortACL <NetworkAccessControlList> | -RemovePortACL] [rest of the parameters]

-PortACL: New optional parameter that lets you set a port ACL to the VM network.

-RemovePortACL: New optional parameter that removes any configured port ACL from the VM network.

Get-SCVMNetwork: Returns the configured port ACL in the returned object.

Sample commands

Get-SCVMNetwork -name VMNetworkNoIsolation | Set-SCVMNetwork -PortACL $acl 

Get-SCVMNetwork -name VMNetworkNoIsolation | Set-SCVMNetwork -RemovePortACL 

VM subnet

These rules will be applied to all VM virtual network adapters that are connected to this VM subnet.

Existing PowerShell cmdlets were updated with new parameter for attaching and detaching port ACLs.

New-SCVMSubnet [–PortACL <NetworkAccessControlList>] [rest of the parameters]

-PortACL: New optional parameter that lets you specify a port ACL to the VM subnet during creation.

Set-SCVMSubnet [–PortACL <NetworkAccessControlList> | -RemovePortACL] [rest of the parameters]

-PortACL: New optional parameter that lets you set a port ACL to the VM subnet.

-RemovePortACL: New optional parameter that removes any configured port ACL from the VM subnet.

Get-SCVMSubnet: Returns the configured port ACL in the returned object.

Sample commands

Get-SCVMSubnet -name VM2 | Set-SCVMSubnet -PortACL $acl 

Get-SCVMSubnet -name VM2 | Set-SCVMSubnet-RemovePortACL 

VM virtual network adapter (vmNIC)

Existing PowerShell cmdlets were updated with new parameters for attaching and detaching port ACLs.

New-SCVirtualNetworkAdapter [–PortACL <NetworkAccessControlList>] [rest of the parameters]

-PortACL: New optional parameter that lets you specify a port ACL to the virtual network adapter while you are creating a new vNIC.

Set-SCVirtualNetworkAdapter [–PortACL <NetworkAccessControlList> | -RemovePortACL] [rest of the parameters]

-PortACL: New optional parameter that lets you set a port ACL to the virtual network adapter.

-RemovePortACL: New optional parameter that removes any configured port ACL from the virtual network adapter.

Get-SCVirtualNetworkAdapter: Returns the configured port ACL in the returned object.

Sample commands

Get-SCVirtualMachine -Name VM0001 | Get-SCVirtualNetworkAdapter | Set-SCVirtualNetworkAdapter -PortACL $acl 

Get-SCVirtualMachine -Name VM0001 | Get-SCVirtualNetworkAdapter | Set-SCVirtualNetworkAdapter –RemovePortACL 

Applying port ACL rules

When you refresh the VMs after you attach the port ACLs, you notice that the status of the VMs is displayed as "Not Compliant" in the Virtual Machine view of the Fabric workspace. (To switch to Virtual Machine view, you have to first browse to either the Logical Networks node or the Logical Switches node of the Fabric workspace). Be aware that VM refresh occurs automatically in the background (on schedule). Therefore, even if you do not refresh VMs explicitly, they will go into a noncompliant state eventually.



At this point, the port ACLs have not yet applied to VMs and their relevant virtual network adapters. To apply the port ACLs, you have to trigger a process that is known as remediation. This never happens automatically and should be started explicitly upon user request.

To start remediation, you either click Remediate on the Ribbon or run the Repair-SCVirtualNetworkAdapter cmdlet. There are no particular changes to cmdlet syntax for this feature.

Repair-SCVirtualNetworkAdapter -VirtualNetworkAdapter <VirtualNetworkAdapter>

Remediating these VMs will mark them as compliant and will make sure that extended port ACLs are applied. Be aware that port ACLs will not apply to any VMs in scope until you remediate them explicitly.

Viewing port ACL rules

To view the ACLs and ACL rules, you can use the following PowerShell cmdlets.

Updating port ACL rules

When you update the ACL that is attached to network adapters, the changes are reflected in all the network adapter instances that use that ACL. For an ACL that is attached to a VM subnet or VM network, all the network adapter instances that are connected to that subnet are updated with the changes.

Note Updating ACL rules on individual network adapters is performed in parallel in a one-try best-effort scheme. Adapters that can’t be updated for any reason are marked "security incompliant," and the task finishes with an error message that states that the network adapters were not updated successfully. "Security incompliant" here refers to a mismatch in expected versus actual ACL rules. The adapter will have a compliance state of "Not compliant" together with relevant error messages. See the previous section for more information about remediating noncompliant virtual machines.

Deleting port ACLs and port ACL rules

An ACL can be deleted only if there are no dependencies attached to it. Dependencies include VM network/VM subnet/virtual network adapter/global settings that are attached to the ACL. When you try to delete a port ACL by using the PowerShell cmdlet, the cmdlet will detect whether the port ACL is attached to any of the dependencies and will throw appropriate error messages.

Removing port ACLs

New PowerShell cmdlets were added:

Remove-SCPortACL -PortACL <NetworkAccessControlList>

Removing port ACL rules

New PowerShell cmdlets were added:

Remove-SCPortACLRule -PortACLRule <NetworkAccessControlListRule>

Be aware that deleting a VM subnet/VM Network/Network adapter automatically removes the association with that ACL.

An ACL can also be disassociated from the VM subnet/VM network/network adapter by changing the respective VMM networking object. To do this, use the Set- cmdlet together with the -RemovePortACL switch, as described in earlier sections. In this case, the port ACL will be detached from the respective network object but will not be deleted from the VMM infrastructure. Therefore, it can be reused later.

Out-of-band changes to ACL rules

If we are doing out-of-band (OOB) changes to ACL rules from Hyper-V virtual switch port (by using native Hyper-V cmdlets such as Add-VMNetworkAdapterExtendedAcl), VM Refresh will show the network adapter as "Security Incompliant." The network adapter can then be remediated from VMM as described in the "Applying port ACLs" section. However, remediation will overwrite all the port ACL rules that are defined outside VMM with those that are expected by VMM.

Core concepts

Each port ACL rule in a port ACL has a property that is named "Priority." Rules are applied in order based on their priority. The following core principles define rules precedence:

• The lower the priority number, the higher the precedence is. That is, if multiple port ACL rules contradict each another, the rule with lower priority wins.

• Rule Action does not affect the precedence. That is, unlike NTFS ACLs (for example), here we don’t have a concept like “Deny always takes precedence over Allow”.

• On the same priority (same numeric value), you cannot have two rules with the same direction. This behavior prevents a hypothetical situation in which one could define both "Deny" and "Allow" rules with equal priority, because this would result in in ambiguity, or a conflict.

• A conflict is defined as two or more rules having the same priority and same direction. A conflict might occur if there are two port ACL rules with the same priority and direction in two ACLs that are applied on different levels, and if those levels partly overlap. That is, there might be an object (for example, vmNIC) that falls within the scope of both levels. A common example of overlapping is a VM network and VM subnet in the same network.

Applying multiple port ACLs to a single entity 

Because port ACLs can apply to different VMM networking objects (or on different Levels, as described earlier), a single VM virtual network adapter (vmNIC) can fall into the scope of multiple port ACLs. In this scenario, the port ACL rules from all the port ACLs are applied. However, the precedence of those rules can be different, depending on several new VMM fine-tuning settings that are mentioned later in this article.

Registry settings

Those settings are defined as Dword values in Windows Registry under the following key on the VMM management server:

HKLM\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings
Please be aware that all these settings will affect the behavior of port ACLs across the whole VMM infrastructure.

Effective port ACL rule priority

In this discussion, we will describe the actual precedence of port ACL rules when multiple port ACLs are applied to a single entity as Effective Rule Priority. Please be aware that there is no separate setting or object in VMM to define or view Effective Rule Priority. It is calculated in the runtime.

There are two global modes in which Effective Rule Priority can be calculated. The modes are switched by the registry setting:

PortACLAbsolutePriority
The acceptable values for this setting are either 0 (zero) or 1, where 0 indicates default behavior.

Relative priority (default behavior)

To enable this mode, set the PortACLAbsolutePriority property in the registry to a value of 0 (zero). This mode also applies if the setting is not defined in the registry (that is, if the property is not created).

In this mode, the following principles apply in addition to the core concepts that were described earlier:

• The priority within the same port ACL is preserved. Therefore, priority values that are defined in each rule are treated as relative within the ACL.

• When you apply multiple port ACLs, their rules are applied in buckets. The rules from the same ACL (attached to a given object) are applied together within the same bucket. The precedence of particular buckets depends on the object to which the port ACL is attached.

• Here, any rules that are defined in the global settings ACL (regardless of their own priority as defined in the port ACL) always take precedence over the rules that are defined in the ACL that is applied to vmNIC, and so on. In other words, layer separation is enforced.
  
  

Ultimately, Effective Rule Priority can differ from the numeric value that you define in the port ACL rule properties. More information about how this behavior is enforced and how you can change its logic follows.

1. The order in which three "object-specific" levels (that is, vmNIC, VM subnet, and VM network) take precedence can be changed.
   
   

   1. The order of global settings cannot be changed. It always takes highest precedence (or order = 0).

   2. For the other three levels, you can set the following settings to a numeric value between 0 and 3, where 0 is the highest precedence (equal to global settings) and 3 is the lowest precedence:
      
      

      • PortACLVMNetworkAdapterPriority (the default is 1)

      • PortACLVMSubnetPriority (the default is 2)

      • PortACLVMNetworkPriority (the default is 3)

   3. If you assign the same value (0 to 3) to these multiple registry settings, or if you assign a value outside the 0 to 3 range, VMM will fail back to default behavior.

2. The way that ordering is enforced is that Effective Rule Priority is changed so that ACL rules that are defined on a higher level receive higher priority (that is, a smaller numeric value). When effective ACL is calculated, each relative rule priority value is "bumped" by the level-specific value or "step."

3. The level-specific value is the "step" that separates different Levels. By default, the size of the "step" is 10000 and is configured by the following registry setting:
   

   PortACLLayerSeparation

4. This means that, in this mode, any individual rule priority within ACL (that is, a rule that is treated as relative) cannot exceed the value of the following setting:
   

   PortACLLayerSeparation(by default, 10000)

Relative priority

To enable this mode, set the PortACLAbsolutePriority property in the registry to a value of 1.

In this mode, the following principles apply in addition to core concepts that are described earlier:

• If an object falls within scope of multiple ACLs (for example, VM network and VM subnet), all rules that are defined in any attached ACLs are applied in unified order (or as a single bucket). There is no level separation and no "bumping" whatsoever.

• All rule priorities are treated as absolute, exactly as they are defined in each rule priority. In other words, the effective priority for each rule is the same as what is defined in the rule itself and is not changed by the VMM engine before it is applied.

• All other registry settings that are described in the previous section have no effect.

• In this mode, any individual rule priority in an ACL (that is, a rule priority that is treated as absolute) cannot exceed 65535.