Veeam on Workgroup, or separate AD Domain

[ferrus]

I'm planning the rebuild of our Veeam infrastructure, and one of the issues that was raised was our lack of an air gap to protect against ransomware attacks - between the production VMs and backup infrastructure.

We don't use Tapes and have no plans to return to using them - so I was planning on widening the gap by isolating the network as much as possible, and putting the Veeam servers on their own AD domain, connecting back to the corporate domain with a one way AD trust.

Recently, we've been using a placeholder Veeam server for the migration, which just exists on a standard Workgroup.
So far, everything has worked well on this server, which has made me reconsider if a separate domain is required.

Are there any benefits or drawbacks from using Veeam on a Workgroup vs Domain? Particularly with regard to security.

[lando_uk]

The simpler the better imo. If i was rebuilding, I'd use workgroup - then it would all still work and you'd be able to login/restore etc should your whole domain be unavailable. Consider firewall/access lists too.

[rsomby]

Going non-itegrated could actually save it from beeing attacked in a bitlocker attack.

[ferrus]

Seems that Workgroup isn't that bad an option.
I still have to work out some details regarding access to the SQL server for staging etc.

Most of the posts I've found regarding Workgroup vs Domain are years old, but mention issues using Sharepoint/SQL Explorers etc.
The recommendations seemed to go in favour of staying on the production domain (in happier times before ransomware attacks).

[frankive]

Hi.
We want to move our veeamserver out of our domain and into workgrop mode.
Will this affect anything on the Veeam server when we log in with the new workgroup user?

[DGrinev]

Hi Frank,

It shouldn't affect anything, also it gives you a certain opportunities like the possibility to use the server even if the DC is down.
Please review the existing discussion as it contains useful considerations. Thanks!

[unsichtbarre]

Should Veeam be joined to a production/user domain?

I advocate for a Veeam B&R installation where the Veeam server is either:

A) Not joined to the domain (Workgroup)
B) Joined to a dedicated Veeam/vSphere (non-user) AD deployment (if this environment will require directory authentication for Compliance)

My logic is based primarily on ransomware, but also on availability as the Veeam Server (and dedicated Veeam/vSphere AD, if created) will be located at the DR site.

Thoughts?
THX

[DGrinev]

Hi John,

You can choose any option that's best fit your needs, since both variants will work properly and have pros and cons.
Please review the existing discussion, it might help you to make a choice. Thanks!

[frankive]

Hi.
We need due to new polcy settings to move a veeam server from domain joined to workgroup.
My approach is to just take the server out of the domain to the workgroup directly.
What issues should I expect to see?
The Veeam server host all the role, f.ex. the sql express database for itself etc.

[andreas2012]

Hi,

We are looking into hardening our backup infrastructure and have bought a new windows server with a lot of disks that we are going to use as a staging server. This server is a repository server, so we have left it in a workgroup.
Then we have the main backup and replication server that has the console, could we also move this server out to a workgroup ?
And we also have 4 veeam proxy servers, could we also move these out to a workgroup ?

Thanks for reply.
Andreas

[DGrinev]

What issues should I expect to see?

Hi Frank,

You shouldn't face any issues switching from domain to workgroup.
Please review the existing discussion. Thanks!

[ejenner]

There are some things to think about if you're putting in a maximum resistance to nasty malware.

You could use 'rotating disks' on your repository. So you take disks out and put other disks in. A bit like tape, but using disks instead.

Another option is to use a mixture of Windows and Linux repositories. Where you have different flavors of OS it's less likely your whole organization could be taken out with one version of a malware infection.

You can do cloud connect as well. So put your Veeam system on an entirely different network and use the cloud connect functionality. But you must have 'Enterprise Plus' license for that.

Lastly, I'd say if you were unlucky enough to have something that nasty on your internal network that I doubt it would be playing fair and only using Microsoft Windows domain or non-domain access methods for getting to your data. If I were writing some nasty code I think I'd probably have it as a design parameter to treat all computers the same rather than trying to distinguish between domained and non-domained machines.

[andreas2012]

Hi,

Thanks for reply. Everything has gone almost ok.. last thing was to move out the main b&r server, but the SQL server that contains the b&r database is still in the domain, so it will fail. How do I change the configuration of Veeam to use the SA account on the SQL server, because i used a domain account under the installation.... and i don`t figure out how to change it

Regards
Andreas

[ASG]

Lastly, I'd say if you were unlucky enough to have something that nasty on your internal network that I doubt it would be playing fair and only using Microsoft Windows domain or non-domain access methods for getting to your data. If I were writing some nasty code I think I'd probably have it as a design parameter to treat all computers the same rather than trying to distinguish between domained and non-domained machines.

The point in non-domain is: You'll have to get credentials to access the Server. No SSO, and if you do non-domain servers for backup these (usually) have another admin password (and some even don't use the "administrator" which is deactivated but use a rather generic username. Former employee for example set r3h24bs as admin-account username for one of the non-domain server...

[ejenner]

The point in non-domain is: You'll have to get credentials to access the Server. No SSO, and if you do non-domain servers for backup these (usually) have another admin password (and some even don't use the "administrator" which is deactivated but use a rather generic username. Former employee for example set r3h24bs as admin-account username for one of the non-domain server...

That protects against one kind of attack where the malware has obtained domain credentials. If a different attack vector were in play having those servers non-dom'ed would provide no protection at all. 'Air-gap' is the wrong way to describe what you've configured.

I see what you're saying though. It depends on how much you want to protect your data. These days I'd say the 3-2-1 rule is more important than ever given the frequency of disclosure sub-OS level vulnerabilities.

[ASG]

That protects against one kind of attack where the malware has obtained domain credentials. If a different attack vector were in play having those servers non-dom'ed would provide no protection at all. 'Air-gap' is the wrong way to describe what you've configured.

I see what you're saying though. It depends on how much you want to protect your data. These days I'd say the 3-2-1 rule is more important than ever given the frequency of disclosure sub-OS level vulnerabilities.

That's not at all 'Air-gap' (I'm pretty sure I didn't imply that because our Air-gap Backup is Offline Tape) - it's an added layer that has to be breached to gain control of the backups (to delete or encrypt them). It targeted the fact that it's not about malware acting different for domain vs. non-domain. And I didn't mean the malware "obtained domain credentials" - I mean SSO (as in Single Sign On). As in "Oh, someone with domain admin rights is running my malware, I don't have to re-authenticate on any other workstation or server since I'm domain admin" type that this should protect againt

[ejenner]

That's not at all 'Air-gap' (I'm pretty sure I didn't imply that because our Air-gap Backup is Offline Tape) - it's an added layer that has to be breached to gain control of the backups (to delete or encrypt them). It targeted the fact that it's not about malware acting different for domain vs. non-domain. And I didn't mean the malware "obtained domain credentials" - I mean SSO (as in Single Sign On). As in "Oh, someone with domain admin rights is running my malware, I don't have to re-authenticate on any other workstation or server since I'm domain admin" type that this should protect againt

The issue is that the original post said 'lack of an air-gap' was a problem. You've answered several months later explaining how you resolved the problem of a lack of an air gap with a strategy of non-domaining... which is not an air-gap.

[ASG]

The issue is that the original post said 'lack of an air-gap' was a problem. You've answered several months later explaining how you resolved the problem of a lack of an air gap with a strategy of non-domaining... which is not an air-gap.

So your posting on 10 Sep 2018 17:38 was not several months before my posting, please stop posting such nonsense. And if you care to read the OP which states as the last question "Are there any benefits or drawbacks from using Veeam on a Workgroup vs Domain? Particularly with regard to security." which my answer was perfectly fine with.

The word air-gap is first mentioned in your reply to MY answer... In the OP there is talk about widening the gap, not air-gap'ing (since he stated that he DON'T want to use tapes). And I even didn't want to say this is air-gap - AND I DIDN'T DO IT. I just can't find anything in my post that let's you consider I said this is air-gap.

ffs

Edit:
And just to repeat it so you MIGHT understand it: IT'S NOT AIR-GAP and it's not my way of air-gap. You didn't seem to read my posts clearly. My air-gap is offline-tape (LTO-8) so "explaining how you resolved the problem of a lack of an air gap with a strategy of non-domaining" is just wrong.

[ejenner]

I'm planning the rebuild of our Veeam infrastructure, and one of the issues that was raised was our lack of an air gap to protect against ransomware attacks

I can see why you're getting frustrated. Go back to the first line of the first post. The whole topic is about air gap.

So my first posting is in response to that. You've then followed up with a strategy, which by being documented here on a topic about air gap... is by implication an air gap strategy. Except what you wrote on a topic about air gap does not describe an air gap. Which is what I said.

[ASG]

Somewhat picky about replying, eh? No word on the 'several months later' part

And you're still wrong - I'm answering on the last question in OP, and now go play somewhere else

[RockemSockem]

How do I change the configuration of Veeam to use the SA account on the SQL server, because i used a domain account under the installation.... and i don`t figure out how to change it

Andreas, I highly recommend that you create a separate SQL login mapped with dbo access to the VeeamBackup database rather than just using the sa login - even if it's a standalone SQL instance with no other databases. There's simply no reason for any application to be using the sa login. Period. If I had $100 for every time I've had that conversation with an ISV, I wouldn't have to work again!

To change the connection string, Veeam has a UI utility for that - Veeam.Backup.DBconfig.exe (Start > Veeam > Configuration Database Connection Settings).

Cheers!

[StevenMeier]

I used the workgroup model at a cloud Service provider I worked for and it worked great.

I am at a new company now and just starting to install veeam in a greenfields setup and I am having discussions about this at the moment using a workgroup model to provide a extra level of security.

[ferrus]

In the end, we did stay with the Workgroup-design, for the backup infrastructure.
So far everything seems to be fine.

Stories like the one in this weeks digest e-mail from Gostev, still fills me with fears about our setup.

I don't hold out much hope that our first tier of backups (on Windows repositories) would survive a complex ransomware attack, even without being domain-joined.
I just hope there's enough of a gap (not air-gap admittedly) on our Data Domains.

I've disabled CIFS entirely, restricted NFS to a single Mtree - from a single Linux VM, and DDBoost to the main VM backup Mtrees.
It's a gamble trying to second guess the reach of malware that still hasn't been created.

[lando_uk]

For a sudu-air gap, having hardware based snapshots of the underlying storage that triggers on completion of the copy job is a good solution.
I realise this needs a SAN/NAS and not cheapo x86 server repositories, but it seems like a pretty good option.

Just don't have your SANs AD authenticated, limit their network access and use local accounts with MFA if possible.

[jwillis1204]

In the end, we did stay with the Workgroup-design, for the backup infrastructure.
So far everything seems to be fine.

Stories like the one in this weeks digest e-mail from Gostev, still fills me with fears about our setup.

I don't hold out much hope that our first tier of backups (on Windows repositories) would survive a complex ransomware attack, even without being domain-joined.
I just hope there's enough of a gap (not air-gap admittedly) on our Data Domains.

I've disabled CIFS entirely, restricted NFS to a single Mtree - from a single Linux VM, and DDBoost to the main VM backup Mtrees.
It's a gamble trying to second guess the reach of malware that still hasn't been created.

Could you forward me that digest? We're in the middle of a big worm resiliency push--definitely want to make sure I'm factoring in everything I can.

Sidebar, I had no idea the digests were a thing. Definitely an awesome perk.

[ferrus]

jwillis1204 - check your PM for the digest.

[stryker54141]

Everyone:

The subject line says it all. Do you install your VBR on your domain or by itself in a workgroup?

David

[foggy]

Hi David, you can review some considerations above. Thanks!

[bdufour]

AD/domain authentication everywhere possible, with MFA set up at the AD level - at least, on highly privileged accounts. Azure seems good.
I don’t like the workgroup idea that much after thinking about it. I think AD MFA, if everything is authenticating through AD, solves the backup appliance and veeam B&R console potential deletion\encryption issue if a privileged account is compromised and gains access to an administrative console. We’ve enabled MFA everywhere possible, but still we see many vendors don’t support it, not just veeam - simple solution is to enable it at the AD level. If you were so unlucky as to have a compromised privileged AD account on your network, having MFA set up on that account would drastically limit the attack vector or thwart it completely. MFA also solves key loggers too..Then you have disgruntled employees! it’s actually a real threat, being able to disable a single AD account to restrict access to critical infrastructure is a great benefit to an institution. Having several separate local accounts, would benefit a disgruntled employee ..that’s why it’s so important for compliance!