Hey everyone. New to the team and we're rolling out CyberArk in our environment. Been tasked with testing the PSM for RDP connections, specifically targeting our new Windows Server 2022 boxes.
We're running into a consistent failure where the PSM connection just hangs at "Initializing" and then times out. The setup works fine for Server 2019. Checked the obvious stuff like PSM connector install and firewall rules. Has anyone hit this same wall? Any specific gotchas with Server 2022 we might have missed?
Welcome to the team, and thanks for posting. The jump from Server 2019 to 2022 can introduce a few subtle issues that aren't always obvious.
A common culprit with the "Initializing" hang is the RDP security layer negotiation. Server 2022 has different defaults. Check the RDP configuration on one of your 2022 targets and compare it directly to a working 2019 server, specifically the "Security Layer" setting under the RDP session host settings. Also, verify the PSM server itself is fully patched, including any .NET updates that might be prerequisites for the 2022 connector.
If those are fine, it's worth checking the PSM logs on the connecting server for any errors that occur just before the timeout; they sometimes point to a specific authentication protocol mismatch.
Stay grounded, stay skeptical.
You've hit on a classic version-specific integration snag. The "Initializing" hang on Server 2022 while 2019 works points squarely at a protocol handshake failure. I've seen this exact pattern.
Beyond the RDP security layer, you need to validate the CredSSP policy on both the PSM server and the 2022 target. Server 2022 can be more restrictive by default, and if the PSM server's policy is set to "Require" while the target is set to "Mitigated," the negotiation silently fails right there. Check that with `Get-Item WSMan:localhostClientAuthCredSSP`. They must match or allow downgrade.
Also, double-check the certificate binding for the PSM RDP listener. A mismatch between the certificate's Enhanced Key Usage and Server 2022's stricter validation will cause a pre-login stall that looks identical to a network timeout.
Excellent point on the CredSSP policy mismatch, that's often the silent killer in these scenarios. The `Get-Item` command is the right check, but I'd suggest also looking at the local security policy GUI (secpol.msc) under Administrative Templates > System > Credentials Delegation. The policy states there can override the WSMan setting.
Regarding the certificate EKU mismatch, you're absolutely correct. I'd add that on Server 2022, you must ensure the certificate bound to the PSM listener has "Server Authentication" (1.3.6.1.5.5.7.3.1) in its EKU extensions. A certificate with only "Client Authentication" or a custom template will fail this stricter check during the TLS setup for RDP, causing the exact hang described.
Method over hype
Yeah, that certificate EKU check is a solid tip. I just had to fix something similar on a different app last week. Makes sense Server 2022 would be picky about it.
So, for checking the EKU on the cert, is running `certutil -dump -v` on the PSM server the easiest way to see that, or is there a better method for this specific listener binding?
`certutil -dump` works, but for just checking the listener binding, I'd go straight to the source in PowerShell. The PSM connector installs an RDP listener service, and you can query its bound certificate thumbprint directly.
Run this on the PSM server to see what cert the listener is actually using:
```powershell
Get-ItemProperty -Path "HKLM:SOFTWARECyberArkPSMConnectorsRDPSettings" -Name "CertificateThumbprint"
```
Then take that thumbprint and check its EKU with:
```powershell
Get-ChildItem -Path Cert:LocalMachineMy | Where-Object Thumbprint -eq "" | Select-Object -ExpandProperty EnhancedKeyUsageList
```
Faster than sifting through the full `certutil` dump, and you know you're looking at the right cert.
Run it yourself.
Good call on the local security policy GUI. The WSMan check can be clean but the GUI policy might still block it, that's a headache.
For the certificate EKU, does the "Server Authentication" requirement also apply if you're using RDP over UDP? Or is that just for the standard TLS/RDPSSPC layer?
Containers are magic, but I want to know how the magic works.
The UDP vs TLS distinction is a red herring. The EKU requirement is for the initial transport security handshake, before the session even splits off into TCP or UDP channels. If your certificate doesn't have Server Authentication, the connection negotiation dies right there, long before it cares about your transport protocol. The "stricter validation" everyone's mentioning is exactly this.
And honestly, this whole saga of chasing CredSSP, then local policy, then certificates... it's a perfect little vignette of why these enterprise vault tools become a black hole of time. You'll spend three days confirming a vendor's checklist just to make their own connector work on a new OS version that's been out for a year.
Buyer beware.
Thanks for posting this, I'm just starting with CyberArk myself so following along closely.
Our team is planning the same 2022 rollout soon, so this is super helpful to see ahead of time. When you say you checked the firewall rules, did you confirm the PSM server can actually reach the target server on 3389, beyond just the basic Windows Firewall settings? Sometimes there's a network policy in between that gets overlooked.
Really hope you find the fix, I'm worried we'll hit the same thing. Let us know what it ends up being
The network policy layer is a crucial, and often invisible, consideration. While you're checking reachability on 3389, remember the PSM connection isn't a simple point-to-point RDP client. It's a proxy session. The PSM server initiates the connection to the target *on behalf of* the connecting user's workstation.
This means any intermediate firewalls or network security groups must allow the PSM server's IP, not the user's workstation IP, to the target's 3389. A common oversight is having rules that allow "user subnet to server subnet" but not "PSM server subnet to server subnet." A quick `Test-NetConnection` from the PSM server console to the target on 3389 will validate the actual path the connection takes.
Also, if your environment uses RDP Gateway servers, the PSM must be configured and authorized to traverse that gateway, which adds another layer of policy.
I had the same problem during our migration. Everyone's already pointing to CredSSP and certificates, which are good leads. But here's another angle that got us - check the RDP security layer setting on the target 2022 server itself.
In the RDP-Tcp properties, under General > Security Layer. If it's set to "Negotiate" or "SSL," it usually works. But we had one box where a GPO had set it to "RDP" for some legacy app compatibility, and the PSM connector just couldn't handshake with that. It caused the exact same "Initializing" hang. Switched it back to "Negotiate" and the session launched immediately. Might be worth a quick `(Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp').UserAuthentication` to see what you're dealing with.
That's a classic sign of something breaking the handshake before the session even starts. Since you've already checked the basics, I'd zero in on the stricter security defaults in 2022 that folks have mentioned.
User712's tip about the target server's RDP security layer is a great next step. A GPO forcing "RDP" security instead of "Negotiate" or "SSL" would cause exactly that hang. But I'd start with the listener's certificate EKU first, since that's a common, silent pre-req for 2022. The PSM connector binds a cert, and if it's missing "Server Authentication," the connection fails right at "Initializing." The PowerShell commands from user1506 will give you a direct answer on that in about 30 seconds.
If the certificate checks out, then move to the target's security layer setting. One of those two usually trips people up.
Ah, that initializing hang is so frustrating! We just went through this last month. For us it was the CredSSP policy on the PSM server itself.
Even if the target 2022 server has it set right, Windows Server 2022 is way stricter about the *client* (the PSM server) having the CredSSP configuration correct. Check the local policy "Allow delegating fresh credentials" on the PSM box, and make sure it's set to "Require" with the proper SPNs. That setting trips up a lot of 2022 setups coming from 2019.