I’m trying to add a bunch of Hyper-V servers (WinRM) to our BFI environment. I’m using the same service account on each, it is a domain account and is in the local administrator’s group. All of the Hyper-V servers are joined to the same domain that the account resides in.
Of the 6 I’ve tried, 4 work fine. The other 2 report authentication failures, and when I have a look at the logs on those two servers I see that the domain & username are reversed.
I’ve tried configuring the username as domain\username, username@domain.tld, username@domain and domain.tld\username. The log shows login failures with this data no matter how I’ve had the username configured:
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: domain.tld
Account Domain: accountname
Obviously domain.tld and account name are the actual values.
If I try to connect from the BigFix server with WinRM directly it works:
winrm enumerate winrm/config/listener /r:hypervserver /u:domain\accountname /p:accountpassword
And I see a successful login in the log with the correct credentials
New Logon:
Security ID: domain\accountname
Account Name: accountname
Account Domain: domain
I’ve tried removing the VM Manager and adding it back but get the same result.
Are you configuring the connections with http (port 5985) or https (port 5986)? Do the settings on the 2 hyper-v host matching? If you are using https, it essentially have to have winrm to listen on 5986 & certificate configured. If the listening on 5986 or certificate are missing it won’t work with https and 5986 (try http only on 5985). Is Basic Auth enabled for WinRM? Is AllowUnencrypted set to true?
Generally, I have found those two pages to be extremely helpful to figure out what is going on both with:
I could’ve swore Auth Basic was listed in the config document but you are right and it’s not. It is certainly in the Troubleshooting link (section 3b) I posted above. In fact there are a lot more detailed steps and settings you can check in the troubleshooting doc than there are in the config one, including event log tracing and whatnot…
Another option you can try is instead of using WinRM to use Powershell - we have the WinRM disabled as a global policy in our environment but Powershell still works (although, they seem to make equivalent calls)… In my experience, Powershell method actually works a lot more consistently than WinRM.