Backup failing due to UAC?

[brupnick]

That is very interesting and something that I was completely unaware of. Now the next set of questions:

1.) Is there a way to grant my new admin account the same rights and permissions that the -500 admin account has?
2.) What if the -500 admin account was deleted? Is there a way to recreate it? (this isn't so much for the VBR issue, but for general information)

[tsightler]

1.) Is there a way to grant my new admin account the same rights and permissions that the -500 admin account has?

You can turn off UAC. That's pretty much the difference. The "default" accounts are hard coded by security policy to be immune to UAC. If you open up your Security Policy Editor and go to Local Policy...Security Options you will find a policy as follows:

User Account Control: Admin approval mode for the Built-In Adminstrator account: Disabled

So basically this is saying that built-in administrator accounts are exempt from UAC since they don't require admin approval mode. If you set this policy to "Enabled" then even the built-in accounts will be subject to UAC.

The Raiders of the Elevated Token is a good video for anyone interested in details of UAC and token elevation.

I don't know if you can easily recreate the "default" account, but I'm sure it could be done somehow.

[brupnick]

This might be a silly question, but is there a difference between built-in accounts (say those that are created when Windows is installed) and accounts that are members of the BUILTIN\Administrators group? I believe the answer to this is "yes," but I want to make sure. The new local admin account that we created is an exact match as far as memberships to the built-in administrator account, but we're still having these UAC issues.

[tsightler]

Yes, that's exactly what this thread has been talking about. The "default" accounts that are created during install are the "built-in" accounts with the known UIDs that end in -500. These are the only accounts that are exempt from UAC by default. Unfortunately Microsoft doesn't provide any method for having a "special" account that is not subject to UAC but also isn't "well known".

[dellock6]

To sum it: "If you are not well known, I'm not going to trust you"
I usually disable UAC at the end, system security is not meant to be the OS asking everywhere for authorization to do something, it's better to work on permissions and policies. Disabling the default admininistrator and rename it is a well established and good practice. I would keep this and disable UAC instead.

Luca.

[brupnick]

Thank you everyone for all of your assistance. I enabled the default administrator account (we had disabled it when we created a new account) and used it in my VBR jobs last night. The two 2008 R2 DCs that I was having issues with were processed as expected. I'm going to work with the rest of my team to change our accounts so that our default domain admin account is the one with the SID ending in -500. I'm also going to discuss this with our Security group to get their thoughts on disabling UAC in certain situations given this new information.

Thank you again,
Brian

[vmnewbie1]

My B&R v6 jobs have been using the DOMAIN\administrator account without issue for the past several months. Over the past two weeks, however, several of my 2008R2 VM backups have started failing 100% of the time with Win32 error Code 53. The only changes we've made were to install the latest round of MS OS updates. What's the likelihood that MS has tightened up UAC even more? Backups work fine once UAC is turned off, but I'd prefer to use my -500 built-in domain admin account, especially since it used to work...

[Andreas Neufert]

Hi just FYI

One of my customers changed some network firewalling things which end up in the following error:

Code: Select all

Failed to prepare guest for hot backup. Details: Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host:  [IP]. Account: [account].
Win32 error:The network path was not found.
Code: 53

Solution:
He opened the port 902 between Veeam Backup & Replication Server and ESX Hosts.

[b.vanhaastrecht]

We are having an issue with a delegated service account for doing the guest index and application aware backups. This account is member of Domain Admins and Builtin\Administrators. When we run the backup job we get an error backup regaring the RPC/Admin$ share isn't accessable. While when we configure the same job with the Domain Administrator account, the job is succesfull. We have rebooted the server to backup, which is a Windows 2012 Server.

Are the permissions set to the service account not enough or could there be an other issue?

Errors when using the service account:

Code: Select all

10-10-2013 10:10:27 :: Failed to prepare guest for hot backup. Error: Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host:  [10.20.35.16]. Account: [].
Win32 error:The network path was not found.
 Code: 53
Cannot connect to the host's administrative share. Host:  [fe80::3013:8eae:8524:8304]. Account: [].
Win32 error:The network path was not found.
 Code: 53

(@Veeam Support: Please note that we are using vCloud level backup, our Veeam backup server has NO network connectivity to the vDC we are trying to backup (usual setup when using vCloud in provider setup). The job first tries to contact the VM via RPC, if that fails the VMware API is used to get to the guest files. The error message above indicates the network is used, but it's actualy doing a fallback to the VMware API, which in this case also failes with a rights issue. The whole VMware API part is not logged in the GUI, this step should be better logged in the GUI.)

[Vitaliy S.]

Hello Bastiaan,

Most likely the account you're using cannot be used to perform VSS freeze operations. You need to either use administrator account (domain, or local machine), or disable UAC to make it work.

Thank you!

[b.vanhaastrecht]

Hi Vitaliy, I've read all pre posts in this thread. Never thought UAC could be the issue. I'm also concerned about the suggested solutions: Disable UAC, or use the builtin administrator account. We are an vCloud service provider, we can't ask for the administrator account of the customers, they just simply wont give it to us. (We need guest indexing because we use the Enterprise Manager to give customers a portal to do their own file restores.) Asking them to disable UAC if an alternative service account is to be used would rase security concerns. There has got to be a MS valid way to assign an account with the appropiate (UAC) rights to do the task nescacary for the guest indexing and application aware backup. Otherwise, Veeams approuch of doing this should be reconsiderd.

Please note my part about the GUI log lacking proper logging about the use of VMware API.

[Vitaliy S.]

Yes, I know about the GUI part. In your case there is a failover while accessing VM via VMware Tools (VIX API), but the fact the local admin works and other accounts that belong to local admin group don't, points that built-in administrator is the only way to use indexing option. BTW, did you open a support case with our team to verify the exact reason for the job failure? This info can be found in the job debug logs.

[b.vanhaastrecht]

Yes, I know about the GUI part. In your case there is a failover while accessing VM via VMware Tools (VIX API), but the fact the local admin works and other accounts that belong to local admin group don't, points that built-in administrator is the only way to use indexing option. BTW, did you open a support case with our team to verify the exact reason for the job failure? This info can be found in the job debug logs.

Ok thanks. I hope Veeam see's the security challenge issue with guest indexing in an vCloud setup. I did not open a support case on this matter. I've done some further testing, and I can confirm it's because of UAC/rights. I'm going to fiddle around in this issue, to see if I can find a way to use a seperate service account with UAC enabled.

[masonit]

Hi!

Maybe I have missunderstood this. But the requirement of using builtin administrator account when UAC is enabled. Does this only apply when using VIX? Or does it also apply when accessing over the network?

\Masonit

[foggy]

Yes, this is VIX-specific requirement. UAC is not enforced on network connections.

[kkuszek]

I am going to bump an old one with a different mindset.

Has anyone looked at or found a way to disable UAC selectively?

I.E. when the veeam service account logs into the machine, do gpo's/login scripts apply to that session? Can UAC be disabled via a gpo or similar at the account and not computer enforcement level so it only compromises during the backup window?

Could VEEAM bypass this limitation on UAC enabled machines by creating a windows task scheduled to run once with elevated permissions and allow task to be run on demand? it could remove the task when quiesced after.

[Vitaliy S.]

Haven't tried that, but you can try do that (disable UAC) as a pre-backup job script.

Could VEEAM bypass this limitation on UAC enabled machines by creating a windows task scheduled to run once with elevated permissions and allow task to be run on demand? it could remove the task when quiesced after.

Do you mean Veeam VSS task? No, it cannot be triggered on demand.

[cbrasga]

I know Veeam is really proud of their "agentless" backups, but perhaps it should also offer a simple agent as an option to allow for the managing VSS snapshots without requiring using the Administrator account or Disabling UAC. Using either workaround is a security risk. Those environments that want to run their backups with a specific service account while leaving UAC in tact on their VMs can simply deploy an agent while maintaining security.

Veeams backup logic could be to use the agent if it exist, if not use remote execution or VIX.

[Vitaliy S.]

Managing and troubleshooting these agents might be painful, but thanks for the feedback. As a solution for now, you may want to try to use pre-freeze and post-thaw scripts.

[DonZoomik]

Can't we login via VIX as NT AUTHORITY\SYSTEM? It has network access, a lot of privileges and no password.
Or is there an API limitation/feature against that? If we could, it would make things a lot easier (no custom credentials per VM).

[Vitaliy S.]

Not sure about this, but you can give it a try.

[Gostev]

If you know the password

[DonZoomik]

You can't set an empty string for password in Veeam. SYSTEM is not supposed to have a password.

[Gostev]

Exactly, which is why you can't logon to a computer with this account

[DonZoomik]

I was checking out the API a few days ago and thinking about it. Remotely, sure you can't. But from OS perspective VIX login should be local...
https://forum.sysinternals.com/best-pra ... 92099.html
If VixVM_LoginInGuest uses Win32 LogonUser, it might work as VMWare Tools as calling process has quite high privileges. VixVM_LoginInGuest of course doesn't have flags to set LOGON32_LOGON_SERVICE...

Or are you just saying that you've tried that and it doesn't work?

[Gostev]

If anything like this was possible, it would be a huge security flaw...

[DonZoomik]

To quote Raymond Chen, you're already on the other side of the airtight hatchway. With access to VMWare, you pretty much have full control of the Guest OS one way or the other and Tools do run under SYSTEM.
But fine, I presume it doesn't work.