• Intro
• How to confirm WDAC enforcement mode in WAC
• Two deployment scenarios
  • Scenario A — Only the managed Azure Local nodes have WDAC enforced
  • Scenario B — Both the managed nodes and the WAC host machine have WDAC enforced
• Adding signer rules to your supplemental policy
• Network and firewall requirements
• PowerShell execution policy
• Known limitations
• Recommendation

Intro

This article is part of a series: Navigate to series page

Windows Admin Center (WAC) is a common management interface for Azure Local clusters. When WDAC is in enforced mode on the managed nodes — or on the machine hosting WAC itself — WAC can encounter connection failures, missing tool functionality, or PowerShell ConstrainedLanguage mode restrictions unless the WDAC policies explicitly allow the required WAC components.

This part covers what you need to configure in your policies and network to make WAC work against WDAC-enforced Azure Local nodes.

How to confirm WDAC enforcement mode in WAC

After connecting to a cluster in Windows Admin Center, go to the Overview page. Under the PowerShell Language Mode field, look for the value:

• FullLanguage — WAC reports full language mode for the connection.
• Constrained — WDAC enforcement is active.

Treat this field as an indicator of the PowerShell session’s language mode, not a complete inventory of active WDAC policies. Constrained is the mode WAC documents as indicating WDAC enforcement; FullLanguage alone doesn’t prove that WDAC is absent or not enforcing other code. When WAC reports Constrained, use the steps below to authorize the WAC components. Initial connections to WDAC-enforced clusters can take several minutes; subsequent connections are typically faster.

Note: After toggling the WDAC enforcement mode on a node (for example, switching between Audit and Enforced), wait at least 30 seconds before reconnecting with WAC so the change is reflected accurately.

Two deployment scenarios

The configuration you need depends on whether WAC runs on a WDAC-enforced machine or not.

Scenario A — Only the managed Azure Local nodes have WDAC enforced

Add the following signer rule to the WDAC policy on the Azure Local nodes. This authorizes WAC’s management modules, which are transferred to the nodes over SMB when WAC connects:

<Signer ID="ID_SIGNER_S_WAC" Name="Microsoft Code Signing PCA 2011">
  <CertRoot Type="TBS" Value="F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E" />
  <CertPublisher Value="Microsoft Corporation" />
</Signer>

Add a corresponding <AllowedSigner SignerId="ID_SIGNER_S_WAC" /> reference in the policy’s UMCI signing scenario (ID_SIGNINGSCENARIO_UMCI). Signer IDs must be unique within the policy; use IDs generated by your policy-authoring tool if they conflict with existing IDs.

Scenario B — Both the managed nodes and the WAC host machine have WDAC enforced

Apply the signer rule from Scenario A on both the managed nodes and the WAC host. Then add these two additional signer rules to the policy on the WAC host machine only:

<!-- Microsoft 3rd Party Application Component signer -->
<Signer ID="ID_SIGNER_S_WAC_3P" Name="Microsoft Code Signing PCA 2011">
  <CertRoot Type="TBS" Value="F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E" />
  <CertPublisher Value="Microsoft 3rd Party Application Component" />
</Signer>

<!-- .NET signer: required for WAC 2410 and later -->
<Signer ID="ID_SIGNER_S_WAC_DOTNET" Name="Microsoft Code Signing PCA 2011">
  <CertRoot Type="TBS" Value="F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E" />
  <CertPublisher Value=".NET" />
</Signer>

Add corresponding <AllowedSigner> references for the additional signer IDs to the WAC host policy’s UMCI signing scenario as well.

Note: The .NET CertPublisher rule is required for Windows Admin Center version 2410 and later. Earlier versions don’t need this rule, but Microsoft documents separate WiX file/hash rules for the WAC host; don’t simply omit the .NET rule without following the instructions for your WAC version.

Adding signer rules to your supplemental policy

These rules can be added to a supplemental policy instead of modifying the base policy, provided the base policy allows supplemental policies. For Azure Local, follow the platform’s policy-authoring and deployment workflow; a new, empty XML file isn’t a valid starting policy. Use the App Control for Business Wizard or another approved policy-authoring workflow to create the signer rules. Microsoft’s WAC guidance recommends generating the publisher rule from the Windows Admin Center .msi and manually adding the additional signer rules where required. Do not assume a certificate at a fixed position in a certificate chain is always the correct certificate to export.

For Azure Local, create a policy XML in Multiple Policy Format with the required signer rules, then use the supplemental-policy cmdlet to convert it to an Azure Local supplemental policy and deploy it cluster-wide. Use the cmdlet that matches the Azure Local release:

$policyPath = "C:\wdac\WAC-supplemental.xml"

# Azure Local 2610 and later
Add-ASAppControlSupplementalPolicy -Path $policyPath

# For Azure Local 2609 and earlier, use this command instead:
# Add-ASWDACSupplementalPolicy -Path $policyPath

In Azure Local 2610 and later, the older WDAC cmdlet remains an alias. These Azure Local cmdlets deploy the policy to cluster nodes; use your organization’s WDAC policy-management process to apply the corresponding rules to a WDAC-enforced WAC host.

Network and firewall requirements

Windows Admin Center transfers management files to managed nodes over SMB and uses WinRM for remote management. Allow TCP 445 for SMB file transfers, and allow the WinRM port or ports configured in your environment (5985 for HTTP and/or 5986 for HTTPS):

Protocol	Port	Purpose
TCP	445	SMB — module file transfer
TCP	5985	WinRM over HTTP, when configured
TCP	5986	WinRM over HTTPS, when configured

If SMB (port 445) is blocked, WAC can’t transfer its PowerShell modules to the node, which can result in “Module not found” or “failed to connect” errors. To check whether WAC transferred its modules, inspect this path on the managed node:

Get-ChildItem "C:\Program Files\WindowsPowerShell\Modules" |
  Where-Object { $_.Name -like "Microsoft.SME.*" }

If no Microsoft.SME.* folders are present, reconnect through WAC and check the SMB path and permissions. Confirm that the WAC host can access TCP 445 on the node and that the account has the required administrative access.

PowerShell execution policy

Microsoft states that the default PowerShell execution policy is sufficient for WAC to manage a WDAC-enforced machine. Don’t change it unless necessary. If you have changed the LocalMachine execution policy and need to restore it to RemoteSigned, run:

Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned

Known limitations

Some WAC features are not supported on WDAC-enforced Azure Local nodes:

Feature	Status
Azure Kubernetes Service deployment via WAC	Not supported in WDAC-enforced environments
Role-Based Access Control (RBAC) on single servers	Not supported under WDAC enforcement
Some Certificates tool operations	Limited or unsupported

Keep these in mind when planning your WAC-based management workflows on WDAC-enforced Azure Local clusters.

Recommendation

Include the WAC signer rules in your approved WDAC policy design for the relevant WAC and managed-node versions. Validate the policy and its supplemental-policy relationship before deployment, and document which signer rules are present and why, following the recommendation from Part 5.

Official Microsoft references: WDAC enforced infrastructure in Windows Admin Center, Manage Application Control for Azure Local, and Windows Admin Center network requirements.