Failed to prepare guest for hot backup. Error: Failed to connect to guest agent. Errors: 'Cannot connect to the host's administrative share. Host: [xx.xx.xx.xx]. Account: [xxx\xxx]. Win32 error:The network path was not found. Code: 53
I noticed this line in the release notes:
Network-less interaction with Microsoft Windows guests having UAC enabled (Vista or later) requires that Local Administrator (MACHINE\Administrator) or Domain Administrator (DOMAIN\Administrator) account is provided on Guest Processing step.
Our backup servers only have a connection to vSphere and storage. They can't access the guest networks. Also, due to security reasons, the 'default' DOMAIN\Administrator account is disabled so I entered another domain administrator account. Is there any way to enable Application-aware backups without disabling UAC or altering the reg key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy?
Hi Rik, no it's not possible. You need to either use administrator account (domain, or local machine), or disable UAC. Can you use local Administrator account on those VMs? Also, note that backup server does not need to be able to access guess networks. Thanks!
What's so special about the dedault Administrator account? Why can't I use a self created local/domain administrator account with a different name than 'Administrator?
Because of how Microsoft designed UAC. And I don't really understand the reasoning behind this design decision either, although I am sure there is one probably...
Rik wrote:What's so special about the dedault Administrator account? Why can't I use a self created local/domain administrator account with a different name than 'Administrator?
Because the "built-in" administrator accounts use well-known security descriptors that are completely exempted from UAC by the default security policy. If you open the Local Security Policy editor, and navigate to Local Policies...Security Options, you will find a policy as follows:
User Access Control: Admin Approval Mode for the Built-in Administrator account: Disabled
Basically this means that the built-in accounts technically have UAC enabled, but are automatically approved for escalation rather than prompted. If you set this policy to enabled, then the built-in accounts are not treated any differently than other admins and they ALL require approval for escalation.
You can read more about well know security principals in Windows here. For anyone super interested, I strongly recommend watching Raiders of the Elevated Token.
6-8-2012 11:29:01 :: Failed to prepare guest for hot backup. Error: Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host: [xx.xx.xx.xx]. Account: [xxx\xxx].
Win32 error:The network path was not found.
Code: 53
Cannot connect to the host's administrative share. Host: [x::x:x:x:x]. Account: [xxx\xxx].
Win32 error:The network path was not found.
Code: 53
Cannot connect to the host's administrative share. Host: [x::x:x:x:x]
There is no network connection between vmware/veeam and the guest networks. Any ideas?
It seems that UAC can't be disabled. It is enforced within the group policies. But I also added the regkey. Is this not enough, or is this only working when there is a network connection between vmware/veeam and the guest VM?
Actually, there is no "thing" you can install in this case... we do not use persistent agents inside guest, so there is no installation package available.
If you change a Group Policy controlled registry setting, it will be over-written by the policy... I believe, registry keys like the above one work if there are no group policy in play that involves it. Otherwise, group policy would be to easy to hack around.
Yes, I know that I can change the GPO, but this is not allowed in the security policy. That's why UAC is enforced through a GPO.
So, there is no way we can make an application aware (VSS) backup with Veeam when UAC is enabled? That's a huge disappointment!
Of course you can make an application aware (VSS) backup with Veeam when UAC is enabled, you just need to provide the account that meets the above-mentioned requirements.
Yes, by using the builtin\administrator or domain\administrator account.
I feel that if you're taking security seriously, disabling these account is one of the first things everyone should be doing when deploying a new environment.
Our security policy is very strict. It's a shame we can't use Veeam as an enterprise backup solution. If there would be a solution for this, Veeam would be perfect!
You can use VMware tools quiescence, instead of Veeam application aware processing. Assuming you are using recent VMware tools this will work and will provide application consistency, although not at the level that Veeam AAP can provide.
Unfortunately the issue that you are seeing is not something that is easy to overcome since it is simply the way that UAC works. With a direct network connection it works because UAC is not enforced on network connections, however, when using "connectionless" mode we are leveraging the VIX API to connect locally to the host. In this case UAC will block any attempts to escalate except for the "built-in" administrator. With UAC local connections attempting to perform administrative task require interactive approval to escalate privileges.
"Security" is all about having balance. You have to decide if having such strict "security" is better than having slightly less than ideal backups (note that VSS isn't required for taking a backup, your backups will be "crash consistent" even without them which is likely all you need in 99% of cases, and if you use recent VMware tools and VMware tools quiescence then you will still have consistent backups). However, it could be argued that not having a 100% consistent backup isn't very good "security" either.
Of course, you may point out that other products that leverage agents can provide backups without this restriction, but that's not really a fair comparison. These agents generally run as a service with privileged status, and then provide an open connection to the world on which the backup server connects, in many cases provided their own, quite weak, authentication. One of the most common methods used by penetration testers is the compromise of these "agents" that are deployed on servers.
Oh Tom, your post reminds me of my past activities in the security field, when I was actually using for real my CISSP certification
Well, the issue is basically security means different things. You can have Confidentiality, Integrity, or Availability (known as the CIA triad). You can't have all of them at the highest level at the same time, so you need to evaluate what is more important for you. Often in backups, integrity is the first goal (be sure your data are the same as you saved them, when you restore them), but then you choose between availability and confidentiality. Encrypted backups are the best example, you prefer to be fast on restores (availability) or be sure only authorized people can restore data?
Everything in a design exercise is about balancing and choosing options...
Luca.
Luca Dell'Oca Principal EMEA Cloud Architect @ Veeam Software
Failed to prepare guest for hot backup. Error: Failed to connect to guest agent. Errors: 'Cannot connect to the host's administrative share. Host: [A.B.50.50]. Account: [DOMAIN\domainadmin]. Win32 error:The network name cannot be found. Code: 67 '
There are firewalls between my VBR server and these two DCs, so RPC fails. This is the case with all VMs in my environment, but the failover to VIX works everywhere else.
As far as I can tell, this issue is related to UAC. If I disable UAC on my DC, the backup is successful. If UAC is anything but disabled, it fails. Disabling UAC is not an option, so are there any ways to get around this? Has anyone else experienced this issue? My support ticket is ID#5210282.
Please correct me if I'm wrong, but because it's a DC, there are no local accounts to use. On my non-DC 2008 R2 machines, using a local admin rather than a domain admin was the fix.
For security purposes, we rename all of our administrator accounts, both local and domain. Is there a way for me to know if one of my renamed accounts was at one point the built-in?
That's very interesting. The account that I'm using does not end in -500, so it is not the default domain administrator account. The account that does end in -500 has been disabled and replaced with a new account (the one that I'm trying to use).
