The CyberArk PAM self-hosted Vault is not typically installed on virtualized hardware but some cases make the scenario justified -- one of them being when standing up a lab environment.
When using Hyper-V (and potentially other hypervisors), after hardening the Vault during the installation process, the Vault may lose network connectivity upon subsequent reboot. This results in the inability to establish inbound or outbound connections for all services.
This issue arises because the Windows Firewall rules created by the CyberArk Vault servers do not take effect, necessitating minor adjustments to two registry keys to resolve the problem.
Determining if your Vault is impacted
The easiest way to tell if you are being impacted by this is by checking the Vault machine's network connectivity. This can be done using
Test-NetConnection and seeing that outbound connections to all services such as Active Directory and the NTP server fail.
Another way is checking the Firewall pane under the Monitoring section in the Windows Defender Firewall snap-in.
This pane shows the rules in effect and when the Vault services are running, four rules representing the allowing of outbound and inbound Vault-related traffic should be showing. If it is empty, then there are no effective rules and no inbound or outbound traffic is allowed.
The fix is straightforward. You simply need to change the two following Windows Defender Firewall-related registry keys from
Afterward, reboot the Vault machine. Rules will show up in the Firewall pane and network connectivity will be restored.
What is happening as part of the hardening?
These keys control if locally defined Windows Defender Firewall rules -- such as the ones created by the Vault when the service starts -- should take effect or not and as part of the Vault hardening, these registry keys are explicitly set to
0 for the Public profile and
1 for the Private profile. It is likely that the intention is for the Vault to take on the Private profile but is for an unknown reason assuming the Public profile.
Even CyberArk is uncertain about why this occurs, as when the Vault hardening process identifies that the Vaults are in AWS, CyberArk explicitly sets both keys to