Skip to main content
  • EN

Hi guys,

First, I’m not sure if I should be posting here or forums.veeam.com?  Either way, here’s my setup:

 

  1. Hyper-V host domain-joined to customer infrastructure, running Windows Server 2022, patched with July 2024 cumulative patches.  Security software includes S1, Threatlocker, and Huntress.  Threatlocker is in “learning” mode and is not blocking anything. 
  1. Backup server is also running Windows Server 2022 patched with the latest July 2024 cumulative update.  Security software includes SentinelOne and Duo authentication to enable MFA for local user logins. Backup box is *not* domain joined at all.

I’ve been told this is a UAC issue, but using a domain user bypasses this problem. I feel like I’m taking crazy pills. No matter what I do, I can’t get the backup server to authenticate with the Hyper-V host using a domain account.  I can get it to authenticate, browse \\hypervip\ADMIN$ share, and connect with Veeam with the built-in, named Administrator account and I can get it to authenticate, browse \\hypervip\ADMIN$ share, and connect with Veeam using other local user accounts after adding the  LocalAccountTokenFilterPolicy registry key to the Hyper-V host.

Using AD\user even after they’ve been added to the local admin group is just not working.  It’s not a username/password issue - I’ve tried with a few different accounts including a domain admin account.  The goal here is to have things as buttoned down as much as possible.  

I was starting to believe this just wasn’t possible.  Even Veeam support seemed to think the only option was to use built-in Admin or use registry key above with a different local user account.  Then I read this thread last night:

can't use non "administrator" account for connecting to Hyper-V host | Veeam Community Resource Hub

@cdmoore1972 stated multiple times that “domain accounts don’t have this issue.”  Is he talking about if both machines are on the same domain, or is he implying that it doesn’t matter if the machine trying to browse to \\hypervip\ADMIN$ is not domain joined?

I think a lot of people might have moved on by now, but I’m going to be moving all customers to Hyper-V and want to make sure I get this right out of the gate.

One more interesting point - I’ve tried with other Windows boxes on the same network to see if they can browse to \\hypervip\ADMIN$ and it doesn’t work, but last night, I randomly tried to access the same share with an apple device over VPN using AD\user and it *was* able to browse the share which makes me think it’s a windows-to-windows authentication issue.

Also, I’ve tried disabling firewalls on both devices - I just haven’t tried fully disabling UAC but to me I would rather use a local admin account and just disable remote uac via registry key vs fully disabling UAC and using domain account.

SentinelOne ?
I have practice and it is very invasive 😊

Just wanted to add - I just tried disabling S1 on both devices and still no luck.  It seems strictly to be a windows authentication issue. Can anyone out there with an identical setup confirm that they were able to get this working using domain credentials?  I’ve been trying for days to make this work and I honestly don’t believe it. 

See this post:

 

See this post:

 

Just tried to download/install and got a “The update is not applicable to your computer.”  I can confirm I got the right version - 21H2 for X64.  Bummer.  Thought that might do the trick.

I should add - I’m seeing event ID 4625 on the Hyper V host and under the area where it says “Account for Which Logon Failed” it’s showing my backup box local username/password and not the domain credentials I’m putting in when getting prompted.

Wanted to through this out there - the primary domain controller is 2019 and not Server 2022.  Could that be the hangup? Nvm - it seems like 2019 and 2022 run the same domain functional level so this *shouldn’t* be the issue.

Update - I’m now able to browse to the admin share if I use the hostname and not the IP address, so I can go to \\SERVERNAME\ADMIN$.  In Veeam the error is different - I get a “Network path not found, or invalid credentials supplied” vs “Failed to connect to host SERVERNAME”

Hey there @frodooftheshire  → Can you check this part of the user guide, and the next “chapter” about permissions for Hyper-V:

System Requirements - User Guide for Microsoft Hyper-V (veeam.com)

Update - I’m now able to browse to the admin share if I use the hostname and not the IP address, so I can go to \\SERVERNAME\ADMIN$.  In Veeam the error is different - I get a “Network path not found, or invalid credentials supplied” vs “Failed to connect to host SERVERNAME”

Hi @frodooftheshire,

we have had some issues with the ip/hostname/dns, which from what i remember looked a little like what you describe in this comment about “network path not found”

For testing we had some success with adding the ip and hostname/FQDN to the VBR servers “hosts” file. When our Hyper-V hosts is in another domain than our VBR - Veeam in some scenarios use NETBIOS and not FQDN throughout the whole process.

can you try to give it a go and see if that helps you in any way?

also as Rick describes, please take a look at the permissions to be sure all is met.

Update - I’m now able to browse to the admin share if I use the hostname and not the IP address, so I can go to \\SERVERNAME\ADMIN$.  In Veeam the error is different - I get a “Network path not found, or invalid credentials supplied” vs “Failed to connect to host SERVERNAME”

Hi @frodooftheshire,

we have had some issues with the ip/hostname/dns, which from what i remember looked a little like what you describe in this comment about “network path not found”

For testing we had some success with adding the ip and hostname/FQDN to the VBR servers “hosts” file. When our Hyper-V hosts is in another domain than our VBR - Veeam in some scenarios use NETBIOS and not FQDN throughout the whole process.

can you try to give it a go and see if that helps you in any way?

also as Rick describes, please take a look at the permissions to be sure all is met.

 

I’m afraid I’ve been trying this as well with no luck.  I added both the FQDN and the hostname to the hosts file and it hasn’t made a difference.  running nslookup and using FQDN and hostname shows the same ipv4 address, which is correct.  I also reviewed the permissions section and I'm not seeing anything.  I updated the ticket I had with Veeam today to include log files.  I’m hoping something will make sense.  The fact that I can browse \\hostname\ADMIN$ using the domain credentials is a good sign.  I’m wondering if it could be something weird with the install.  What’s tough is I could just use the registry hack, and disable remote UAC, but if this *can* work with domain credentials without disabling remote UAC that’s going to be by far the best way to do it.

You mentioned your EDR platform… I will say our support team has told me that they are seeing more interference with EDR platforms and the Veeam data flow. Makes me think about disabling parts temporarily and seeing how it does to identify at least why...

Hi everyone,

 

After quite a bit of work, I finally discovered the root of the problem.  There were group policy settings in place that denied all authentication with NTLM.  Because my backup box is not on the domain and thus can’t use Kerberos, it was falling back to NTLM. I modified the group policy to only respond to NTLMv2 and made an exception for my backup box.  I’m now able to authenticate with Hyper-V just fine.

Thanks for letting us know @frodooftheshire → Maybe  add a comment with some of the texts of the errors so that if someone searches (here, Bing, Google, etc.) ; they’ll end up to this.

Thanks for letting us know @frodooftheshire → Maybe  add a comment with some of the texts of the errors so that if someone searches (here, Bing, Google, etc.) ; they’ll end up to this.

Hi Rick,

Absolutely.  I was seeing EVENT ID 4625 in the security logs - unknown user name or bad password even though the credentials were correct.  Hope this is maybe helpful for others in the future.

Still having issues.  @frodooftheshire .  I have one 2022HV host (no domain joined), Veeam  11 running on Windows 10 in the same network and this backs up just fine.  No special changes made but I am using the built in Admin account.  The second HV host is also Server 2022 and is in a remote location connected via VPN tunnel.  DNS all works fine and I can browse to the admin$ by name (\\servername\admin$).  I have down this rabbit hole with other host in this config some work some do not.  Firewall disabled, UAC disabled I made what I believe is the correct GPO you referenced but still the same error everyone else see’s.  I don’t recall if I have even had this issue on Veeam 11 which is why I still use it but V12 for sure never works.  Thoughts on this one?

Still having issues.  @frodooftheshire .  I have one 2022HV host (no domain joined), Veeam  11 running on Windows 10 in the same network and this backs up just fine.  No special changes made but I am using the built in Admin account.  The second HV host is also Server 2022 and is in a remote location connected via VPN tunnel.  DNS all works fine and I can browse to the admin$ by name (\\servername\admin$).  I have down this rabbit hole with other host in this config some work some do not.  Firewall disabled, UAC disabled I made what I believe is the correct GPO you referenced but still the same error everyone else see’s.  I don’t recall if I have even had this issue on Veeam 11 which is why I still use it but V12 for sure never works.  Thoughts on this one?

Well you can disregard.  Apparently I had a senior moment and had not installed the HV role yet.  This server was racked weeks ago and I thought I had it ready.  

Never thought of ensuring the role was there!

Comment


Terms & Conditions