Domain Admin account and Veeam

[Stabz]

Hello,

Currently, we use a domain admin service account for manage my Veeam B&R solution (jobs, vcenter integration, etc)---> bad.
In a context of PCI-DSS compliance, we must limited the usage of domain admin account.

I'm looking for the best practice to implement Veeam with the principle of least privilege.

Already read this posts:
veeam-backup-replication-f2/an-ad-veeam ... 43585.html
veeam-backup-replication-f2/credentials ... 47689.html

For the job part if my understanding is correct
-Application aware processing need an admin account to access to ADMIN$ of the guest VM
Solution: use a local admin account where application aware processing is needed. All Vms without AD,SQL,Exchange dont need this option so we could disable it right?
To improve the security this local admin
But what is the solution for Domain Controller ?

-Guest File system indexing need an account too, which privilege this account needs ?

Thanks

[HannesK]

Hello,
yes, local admin is fine for everything except domain controllers where they don't exist.There you need a domain admin.

Indexing (if you really need it), is the same: local admin.

Did you see the "required permissions" document in helpcenter? It also includes the requirements for VCenter access.

Best regards,
Hannes

[DonZoomik]

yes, local admin is fine for everything except domain controllers where they don't exist.There you need a domain admin

Actually, BUILTIN\Administrators seems to work fine on DCs. It has admin privileges on DCs but not on member servers.

[HannesK]

I'm not sure whether we are talking about the same thing. there are no "local" user on domain controllers

normal server


domain controller - no local users

[DonZoomik]

Take a look at "Builtin" container in for example "Active Directory Users and Computers" MMC snap-in.
These groups are considered "local" to DCs (as in they are shared over DCs).

[HannesK]

(as in they are shared over DCs).

"shared" is the opposite of "local" for me, but I believe that does not change anything

[DonZoomik]

Details, true. But from compliance perspective you don't have to give Veeam "Domain Admins" account (that has by default keys to pretty much everything). Create for example a domain-controller specific service account and set it as member of BUILTIN\Administrators. This account can self-elevate to Domain Admins if credentials are stolen, but by default it doesn't have access to everything.

[Stabz]

Thanks you to both of you for this advices
Yes I checked the helpcenter and this documentation https://www.veeam.com/veeam_backup_9_0_ ... ons_pg.pdf,

DonZoomik, I ll take a look to your solution which seems to be the greatest approach

Do you know if we can just enable the following rights:
Logon as a batch job granted
Deny logon as a batch job not set

and block the others rights (logon localy or RDP,...)

[nmdange]

I use native quiescence when backing up domain controllers so Veeam does not need a domain admin account to backup DCs. The host initiates the VSS snapshot within the guest so it's still application consistent. You can also still do item-level restores with AD Explorer even when the VM didn't get backed up with application-aware processing.

[DonZoomik]

If you use tools quiescence, you can't natively do non-authorative (whole VM) restore. You have to a few things yourself.

I'd just look here https://blogs.technet.microsoft.com/sec ... rver-2019/ or use older baselines per your OS version or whatever your compliance baseline requires. I don't think I've seen any baseline require setting it (but my memory is quite bad), neither does Microsoft.
It basically controls what users are allowed to be run as from Task Scheduler. If you have maybe a regular maintenance task running on your DC, it'd likely be blocked if you set it to deny.

I have done some minor modifications for my own purposes as some options block even remote admin. Test before you lock yourself out (console login usually continues to work).

[Stabz]

Ok ! Thanks I'll create a new test job and test all this thing!

[nmdange]

Yes that is true, but there is little reason to ever do a non-authoritative restore of a DC. Just do a metadata cleanup and rebuild the broken DC. It's a tradeoff, but not storing domain admin creds in Veeam is a good tradeoff imo

[DonZoomik]

Yes, it's a tradeoff. On the other hand restoring broken DC VM in a few clicks (i've had to do that) instead of rebuild is much easier, a tradeoff.

[bdufour]

builtin\administrator is all you need for the DCs - ive been running veeam for many years this way. local admin - servers / builtin\administrator - DCs, no domain admins accounts in the mix. although, its true, that with builtin\administrator permissions you can elevate to other more privileged groups - thats why having proper alerting on privileged accounts is necessary. for instance, having an alert set up for domain admin group modification (say an account is added to that group).

[Stabz]

Hello guys,

I did some tests. The Builtin\Administrator group works perfectly.
My alarm was already set to alerting in case of domain admin group modification.

Now I want to limite the users rights assignement of my service account, in the documentation I found this:
Note that for Veeam Backup & Replication version 9.5 Update 3a and later, the account used for guest OS processing must have the following user rights assigned:
Logon as a batch job granted
Deny logon as a batch job not set

I applyed this rules and added this:
Deny log on locally and Deny log on through Terminal Services

But I obtain an alarm from my monitoring, failed logon
Details: Cause: The user has not been granted the requested logon type at this machine.
This entry represents 68 matching events occurring within 600 seconds.

In the event logs I have this:
An account failed to log on.

Subject:
Security ID: SYSTEM
Account Name: XXX$
Account Domain: XXXX
Logon ID: 0x3e7

Logon Type: 2

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: svc-veeam-test
Account Domain: XXXX

Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
Status: 0xc000015b
Sub Status: 0x0

Process Information:
Caller Process ID: 0x4b4
Caller Process Name: C:\Program Files\VMware\VMware Tools\vmtoolsd.exe

[Stabz]

Support case opened: Case # 03441663

I hope to obtain an answers soon.

[JPomper]

Did you ever figure out that last bit with the audit failures? I am running into the same thing. vmtoolsd.exe calling with veeam service account (that has the permissions/local security settings needed) failing to logon type 2.

[HannesK]

Hello,
and welcome to the forums.

As the case was in French, I can only summarize the internal support recap. Maybe it helps:

There was a group policy that did "Deny log on locally and Deny log on through Terminal Services". This does not work for log truncation. AD doesn't need to truncate the transaction logs. They disabled SQL log truncation for the VM.

Best regards,
Hannes

[OregonSteve]

Re: local admin account... I've been trying this and it's failed every time. I've been using the naming format: '.\username' I found in another post that it needs to be in the form of 'computername\username'. Am I supposed to create 200 separate credentials to back up my 200 devices?

Thanx
OregonSteve
"Never never doubt what nobody is sure about." -Willy Wonka

[soncscy]

Hi Steve,

For your scale, I usually see two directions:

1. Service Account(s) with frequently rotated passwords. Cycle the passwords in AD with some password manager and just use a simple script with Get/Set VBRCredentials: https://helpcenter.veeam.com/docs/backu ... ml?ver=100

The general flow is:

- Use the password utility to produce a new password as a Secure String
- Push the new credential to AD and let it percolate down to the machines
- At the same time, update the corresponding credential in Veeam

2. Some complex AD Domain account situation. I will be skimpy on this as I usually don't really like messing with Active Directory unless I have to, but it's just not my comfort zone.

Automation tasks are why scripts are built and unless you have a password management solution built to rotate your passwords for you, then you just do simple scripts.

[rcomeau]

We were just discussing this internally (I do internal IT for an IT firm).

This is what we've come up with:

• Create a veeam service account
  Grant the veeam service account local admin priviledge
  Push via GPO, ensure this is denied to domain controllers (since they don't have local admin groups
  Create a veeam service account specifically for domain controllers
  Grant the veeam service DC account domain admin permissions
  Set to login as a service
  Set 'log on to' to only your DCs
  Configure DC machines to use these creds only

Going to open a ticket with Veeam, but this sounds to be the most sound way of going about least privilege and keeping to PCI.

[HannesK]

Hello,
and welcome to the forums.

I did not try your solution, but it sounds as it can work.

If you never do full-VM restore of a domain controller, then you can also just do crash-consistent backup. The Veeam Explorers for AD still works fine.

Would group managed service accounts be compliant with PCI DSS? If yes, then V12 has a more comfortable solution.

Support is available to fix things. They are not professional service / consulting resources. So support will just point to the user guide saying "you need administrator permissions".

Best regards,
Hannes

[ConradGoodman]

HannesK,

Apologies for dragging up an old thread, but we are in a similar situation to others in this thread.

I am testing a backup of our DCs now having removed the Veeam account from Domain Admins.

Is it categorically the case that the account only needs to be a member for restores?

I.e. I can continue to backup interactively with the same account being just a domain member, and then add to the Domain Admins group in the scenario of a DC restore?

[HannesK]

Hello,
I got lost a bit what is configured

I am testing a backup of our DCs now having removed the Veeam account from Domain Admins.

so you do crash consistent backup? No application aware processing enabled? Technically that works fine as long as you don't do full VM restores (well, should also work on modern Windows, but I'm still USN rollback minded...)

Is it categorically the case that the account only needs to be a member for restores?

for object level restore, a domain admin is needed. Credentials will be asked during restore. Only domain admins can restore active directory with the Veeam Explorer for AD

I.e. I can continue to backup interactively with the same account being just a domain member, and then add to the Domain Admins group in the scenario of a DC restore?

did that work? because application aware backup should fail on a domain controller with a non domain-admin account (because VSS requires a domain admin, because there is no local admin on a DC)

Best regards,
Hannes

[ConradGoodman]

Hey Hannes

I have tested all the scenarios.

We do use interactive backup with the DCs.

We have DCs in the forest root and 2 child domains all protected in one job.

I created separate Veeam service accounts, in all 3 domains.

These accounts were added to BUILTIN\Administrators in their respective domain.

The accounts were then added to the local 'Administrators' group on the Veeam Server in the respective domain (as we back it up interactively too).

The file server also has this account as local admin.

I edited the job that backs up all our domain controllers, and used the specify credentials option to override the default account, with the appropriate account for the given domain controller.

All this works without anything being in Domain Admins, and our insurer has approved it.

[HannesK]

Hello,

These accounts were added to BUILTIN\Administrators in their respective domain.

agree, that group has no access to the computers per default and would work for DCs. But the builtin\administrators have full permissions on the domain. so they can add themselves to the domain admins group. Technically you are right, but I don't see any advantage from a security standpoint.

Best regards,
Hannes

[ConradGoodman]

indeed, just a box ticket exercise to meet a BS requirement!

[maanlicht]

Another 2 years later...
We ran an experiment where we deployed unmanaged agents on our DCs. These run under the ‘System’ account. They allow to enable guest-processing without the need to provide any (domain admin) credentials. AD item level restores where successful.
The tradeoff here is that:
1. The agents would need to be manually managed.
2. Powershell automation for unmanaged agents is limited. You won’t be able to add the agent to a copyjob with powershell. That’s a manual process too.

Has anyone tested with the relatively new ‘Persistent Agent Components’ feature?

[HannesK]

Hello,
persistent guest agents work fine (including domain controllers), but require credentials to be stored on the backup server.

Best regards,
Hannes

[matteu]

Pre provision agent is the way you should go if you don t want to store credential on VBR server.
I use it since 1 year on all my customer and it s working fine