Deny Access for Domain Admin

[vota]

Is it possible to deny access to B&R-Console for the Domain Admin(Domain\Administrator)?

I tried to remove the Domain Admins Group from the Local Administrator Group and also assigning the Viewer Role the domain\adminstrator but the user still have full access to the hole Configuration.

Thanks!

[PTide]

Hi,

Have you tried to assign Veeam Backup Administrator role to the local admin (HOSTNAME\Administrator) and delete all other accounts that are related to the domain admin?

Thanks

[vota]

Yep - even if i delete everything else like in the screenshot below, the administrator is still able to logon with full accessrights:

[foggy]

Hi Stefan, how do you tell that the account has full access?

[vota]

When I logon to B&R Console I can edit everything

[foggy]

Well, looks like there's no ability to do what you're after. Built-in administrator accounts (Domain\Administrator and Machine\Administrator) always have full access, even if excluded from all Veeam B&R roles. This is done as a workaround for situations when all accounts are removed from the Veeam Backup Administrators role for some awkward reason.

[larry]

Remove the domain admins from the server local admin group, be careful you have a server account to use to add back if needed.

[vota]

Remove the domain admins from the server local admin group, be careful you have a server account to use to add back if needed.

As mentioned in my first post i already tried this - without success...

Well, looks like there's no ability to do what you're after. Built-in administrator accounts (Domain\Administrator and Machine\Administrator) always have full access, even if excluded from all Veeam B&R roles. This is done as a workaround for situations when all accounts are removed from the Veeam Backup Administrators role for some awkward reason.

will there be a possibility in the future(e.g. 9.5)?

[foggy]

I don't think so, since this is a precaution measure.

[nmdange]

Are you testing with the default Active Directory Administrator account (i.e. the account named "Administrator") or a new account that is in the Domain Admins group? I suspect the built-in Administrator account is different from a new account that is only in the Domain Admins group. As a security best practice, you should not be using the default Administrator account with Active Directory. You should create a separate domain admin account for each employee that needs domain admin privs and then reset the default Administrator account's password to something extremely long and complicated and never use the account again.

[Mike Resseler]

I have to agree with nmdange. If you want something like this, you can't use internally the administrator account (the one that is actually named administrator). That account is always going to have rights on all domain servers (you would be able to override that with a deny through a GPO but if you do... Be very careful, I have been called in an environment where the ONLY administrator was denied access to ALL servers in the environment...)

When you are indeed working with a separate account, you can deny those specific domain admins access to a server and also deny access to B&R. But again, you will need to look at the GPO because probably there is a rule in your environment that automatically adds the domain admins to the local administrator group

[thomas.biesmans]

Not sorry to resurrect this old thread because it's increasingly valid these days. Cfr. link ransomware in 2020 tends to linger, collecting information while triggering the nasty parts outside of regular working hours several days after they gained entry.

I'm on the fence whether you should assume AD is compromised. Either way I'd recommend performing the following tasks:
- You should limit access to the backup server infra. These days I'd advise a single local admin user. Domain admins and other domain users should be removed from the local Administrators group.
- GPOs should be disabled, for what it's worth the following WIP list should cover this:
o Lock permissions of 'HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies'
o Rename 'gpupdate.exe'
o "Local Computer Policy" > "Computer Configuration" > "Administrative Templates" > "System" > "Group Policy" > "Turn off background refresh of Group Policy".
- Any other AD mitigations I'm not aware of, we're only recently started focussing on this.

Imho: granting the built-in domain admins administrative access to Veeam by default and not being able to override this is a very bad approach and leaves you extremely vulnerable, assuming attackers will find ways to elevate their rights eventually. There are better ways for the use case you mentioned. One way I often see in other products is having a local executable on the backup server itself that is able to reset administrative access to the application. I find this a much better approach.

Now, my problem: I like having the backup server in AD. This allows me to look up AD user accounts, but also allows Agent configuration based on OUs, etc. As it is, and if I'm not missing anything I find it very hard to recommend joining backup servers to AD.

[Gostev]

Now, my problem: I like having the backup server in AD. This allows me to look up AD user accounts, but also allows Agent configuration based on OUs, etc. As it is, and if I'm not missing anything I find it very hard to recommend joining backup servers to AD.

Hmm, but having the backup server in AD is not required to be able to connect to AD and retrieve it's information? You can certainly connect to AD from a non-domain joined computer, if you have credentials from that AD.

[thomas.biesmans]

Hm, I most likely overestimate what joining AD offers then. Looks like the agent protection groups and possible AD lookups are indeed very well handled by allowing you to add a domain with specific credentials. So looks like Veeam-wise that would only leave adding AD users for authorization (Users and Roles), which is based on the regular Windows local / AD user lookup window, so no idea how that would function in a workgroup environment?

Seems like we'll be transitioning to workgroup environments either way as a hardening best practice.