For more information about Update Rollup 8 for System Center 2012 R2 Virtual Machine Manager, click the following article number to view the article in the Microsoft Knowledge Base:
3096389 Update Rollup 8 for System Center 2012 R2 Virtual Machine Manager
Glossary
We have improved the Virtual Machine Manager object model by adding the following new concepts in the network management area.
- Port access control list (port ACL)
An object that is attached to various VMM networking primitives to describe network security. The port ACL serves as a collection of access control entries or ACL rules. An ACL can be attached to any number (zero or more) of VMM networking primitives, such as a VM network, VM subnet, virtual network adapter, or the VMM management server itself. An ACL can contain any number (zero or more) of ACL rules. Each compatible VMM networking primitive (VM network, VM subnet, virtual network adapter, or VMM management server) can have either one port ACL attached or none. - Port access control entry or ACL rule
An object that describes filtering policy. Multiple ACL rules can exist in the same port ACL and apply based on their priority. Each ACL rule corresponds to exactly one port ACL. - Global Settings
A virtual concept that describes a port ACL that is applied to all VM virtual network adapters in the infrastructure. There is no separate object type for Global Settings. Instead, the Global Settings port ACL attaches to the VMM management server itself. The VMM management server object can have either one port ACL or none.
For information about objects in the network management area that were previously available, see
Virtual Machine Manager Network Object Fundamentals.
What can I do with this Feature?
By using the PowerShell interface in VMM, you can now take the following actions:
- Define port ACLs and their ACL rules.
- The rules are applied to virtual switch ports on Hyper-V servers as "extended port ACLs” (VMNetworkAdapterExtendedAcl) in Hyper-V terminology. This means that they can apply only to Windows Server 2012 R2 (and Hyper-V Server 2012 R2) host servers.
- VMM will not create the "legacy" Hyper-V port ACLs (VMNetworkAdapterAcl). Therefore, you cannot apply port ACLs to Windows Server 2012 (or Hyper-V Server 2012) host servers by using VMM.
- All port ACL rules that are defined in VMM by using this feature are stateful (for TCP). You cannot create stateless ACL rules for TCP by using VMM.
For more information about the Extended port ACL feature in Windows Server 2012 R2 Hyper-V, see Create Security Policies with Extended Port Access Control Lists for Windows Server 2012 R2. - Attach a port ACL to Global Settings. This applies it to all VM virtual network adapters. It is available only to full admins.
- Attach the port ACLs that are created to a VM network, VM subnets, or VM virtual network adapters. This is available to full admins, tenant admins, and self-service users (SSUs).
- View and update port ACL rules that are configured on the individual VM vNIC.
- Delete port ACLs and their ACL rules.
Each of these actions is covered in more detail later in this article.
Please be aware that this functionality is exposed only through PowerShell cmdlets and will not be reflected in the VMM console UI (except for the "Compliance" state).
What can I not do with this feature?
- Manage/update individual rules for a single instance when the ACL is shared among multiple instances. All rules are managed centrally within their parent ACLs and apply wherever the ACL is attached.
- Attach more than one ACL to an entity.
- Apply port ACLs to virtual network adapters (vNICs) in the Hyper-V parent partition (management OS).
- Create port ACL rules that include IP-level protocols (other than TCP or UDP).
- Apply port ACLs to logical networks, network sites (logical network definitions), subnet vLANs, and other VMM networking primitives that were not listed earlier.
How do I use the feature?
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
Define port ACL rules for the port ACL
Each port ACL consists of a collection of port ACL rules. Each rule contains different parameters.
- Name
- Description
- Type: Inbound/Outbound (the direction in which the ACL will be applied)
- Action: Allow/Deny (the action of the ACL, either to allow the traffic or to block the traffic)
- SourceAddressPrefix:
- SourcePortRange:
- DestinationAddressPrefix:
- DestinationPortRange:
- Protocol: TCP/Udp/Any (Note: IP-level protocols are not supported in port ACLs that are defined by VMM. They are still supported natively by Hyper-V.)
- Priority: 1 – 65535 (lowest number has highest priority). This priority is relative to the layer in which it is applied. (More information about how ACL rules are applied based on priority and the object to which the ACL is attached follows.)
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-SCPortACLruleRetrieves 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 commandsGet-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.
New PowerShell cmdlets that are added
Retrieve port ACLsParameter set 1. To get all or by name:
Get-SCPortACL [-Name <>]
Parameter set 2. To get by ID:
Get-SCPortACL -Id <> [-Name <>]
Retrieve port ACL rules Parameter set 1. All or by name:
Get-SCPortACLrule [-Name <>]
Parameter set 2. By ID:
Get-SCPortACLrule -Id <>
Parameter set 3. By ACL object:
Get-SCPortACLrule –PortACL <
NetworkAccessControlList>
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.
New PowerShell cmdlet added
Set-SCPortACL -PortACL <
PortACL> [-Name <
Name>] [-Description
<description>]
Set-SCPortACLrule -PortACLrule <
PortACLrule> [-Name <
name>] [-Description <
string>] [-Type <
PortACLRuleDirection> {Inbound | Outbound}] [-Action <
PortACLRuleAction> {Allow | Deny}] [-SourceAddressPrefix <
string>] [-SourcePortRange <
string>] [-DestinationAddressPrefix <
string>] [-DestinationPortRange <
string>] [-Protocol <
PortACLruleProtocol> {Tcp | Udp | Any}]
Set-SCPortACL: Changes the port ACL description.
- Description: Updates the description.
Set-SCPortACLrule: Changes the port ACL rule parameters.
- Description: Updates the description.
- Type: Updates the direction in which the ACL is applied.
- Action: Updates the action of the ACL.
- Protocol: Updates the protocol to which the ACL will be applied.
- Priority: Updates the priority.
- SourceAddressPrefix: Updates the source address prefix.
- SourcePortRange: Updates the source port range.
- DestinationAddressPrefix: Updates the destination address prefix.
- DestinationPortRange: Updates the destination port range.
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.
Port ACL rule priority and application precedence (advanced)
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.
- The order in which three "object-specific" levels (that is, vmNIC, VM subnet, and VM network) take precedence can be changed.
- The order of global settings cannot be changed. It always takes highest precedence (or order = 0).
- 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)
- 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.
- 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."
- 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
- 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)
Configuration example
Assume that all the settings have their default values. (These are described earlier.)
- We have an ACL that is attached to vmNIC (PortACLVMNetworkAdapterPriority = 1).
- The effective priority for all rules that are defined in this ACL is bumped by 10000 (PortACLLayerSeparation value).
- We define a rule in this ACL that has a priority that is set to 100.
- The effective priority for this rule would be 10000 + 100 = 10100.
- The rule will take precedence over other rules within the same ACL for which the priority is greater than 100.
- The rule will always take precedence over any rules that are defined in ACLs that are attached on the VM network and VM subnet level. (This is true because those are considered to be "lower" levels).
- The rule will never take precedence over any rules that are defined in the global settings ACL.
Advantages of this mode - There is better security in multi-tenant scenarios because port ACL rules that are defined by the Fabric admin (on the Global Settings level) will always take precedence over any rules that are defined by tenants themselves.
- Any port ACL rule conflicts (that is, ambiguities) are prevented automatically because of layer separation. It is very easy to predict which rules will be effective and why.
Cautions with this mode - Less flexibility. If you define a rule (for example, "Deny all traffic to port 80") in global settings, you can never create a more granular exemption from this rule on a lower layer (for example, "Allow port 80 only on this VM that runs a legitimate web server").
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.
Configuration example
- In the global settings ACL, you define a rule whose priority is set to 100.
- In the ACL that is attached to vmNIC, you define a rule whose priority is set to 50.
- The rule that is defined on the vmNIC level takes precedence because it has a higher priority (that is, a lower numeric value).
Advantages of this mode- More flexibility. You can create "one-off" exemptions from the global settings rules on lower levels (for example, VM subnet or vmNIC).
Cautions with this mode - Planning might become more complex because there is no level separation. And there can be a rule on any level that overrides other rules that are defined on other objects.
- In multi-tenant environments, security can be affected because a tenant can create a rule on the VM subnet level that overrides the policy that is defined by the Fabric admin at the global settings level.
- Rule conflicts (that is, ambiguities) are not eliminated automatically and can occur. VMM can prevent conflicts only on the same ACL level. It cannot prevent conflicts across ACLs that are attached to different objects. In cases of conflict, because VMM cannot fix the conflict automatically, it will stop applying the rules and will throw an error.