I'm attempting to connect to an Entra-joined device using WinRM over HTTPS from a machine that is part of a domain. The setup is as follows: my source machine is domain-joined, and the target is a workgroup machine (Entra-joined). I've ensured that HTTPS (port 5986) is open, a valid certificate is deployed on the remote device, and the WinRM listener is configured for HTTPS. However, when I run the command 'Test-WSMan -ComputerName "xxx" -UseSSL -ErrorAction Stop', I encounter an error stating that the WinRM client cannot complete the operation. I have some important observations: it works fine with domain-joined machines using Kerberos, the Entra device isn't registered in DNS, and name resolution fails unless I use the IP address. Here are my questions: 1) Are there limitations when using WinRM between these types of devices? 2) What's the best authentication method for this scenario—NTLM, Basic over HTTPS, or a certificate? 3) Is DNS registration necessary, or can I rely on IP or the hosts file? 4) Do Entra-only devices require any specific WinRM configurations? I feel like there's something fundamental I'm missing regarding how WinRM works without AD/Kerberos in the mix. Any insights would be appreciated!
4 Answers
Without specifying the Authentication parameter, WinRM defaults to Kerberos. After confirming your name resolution is working, you might want to give CredSSP a shot. Additionally, if you haven’t already, consider setting up Cloud Kerberos Trust; this allows Entra logins to use Kerberos assuming you’re using Windows Hello for Business or Windows Sign-In.
If you’re having name resolution issues, that’s the first thing to tackle. Check if you're using the FQDN correctly and if your DNS settings are pointing to the right servers. If the DNS isn’t working, you might need to adjust DHCP options. Once you fix that, you can move forward with fixing any remaining issues. If you’re using self-signed certificates, ensure the right certificate authority is imported on the device, and compare the settings with a working machine.
But aren't Entra devices basically like Workgroup machines?
Make sure you’re using the FQDN for the remote machine, as it’s essential for proper DNS resolution. Also, verify that the firewall on both machines has the WinRM service allowed. You might want to test by temporarily disabling the firewall to see if that’s the culprit. Additionally, confirm that the certificate is trusted on both ends; it may need to be added to your trusted devices on the client side. Since you’re not using Kerberos, you might have to provide credentials and set the authentication type to basic.
Does that mean I need to deploy the cert on the client side too?
Honestly, I've also had similar frustrations with WinRM. After several Windows updates, it became almost impossible to maintain connections without constant reconfiguration. We tried using Windows Admin Center, but that became useless due to these ongoing issues.
What causes those disruptions, though? Is it the updates themselves?
I tried the recommended command but got the same error.