Veeam servers not joined in AD?

[perjonsson1960]

Folks,

I just read this week's "Word from Gostev", which was an eye opener... The bottom line there is that, as I understand it, the Veeam backup servers should NOT be joined in the Active Directory since a AD-admin user that has been taken over by a ransom virus, would be able to encrypt the Veeam backup files.

But my question is: If the backup servers are not joined in the AD, then it will not be possible to do backups of AD objects like file- and SQL-cluster objects? Or am I wrong? We are currently backing up our physical fileserver cluster and our physical SQL cluster via the AD cluster objects as that. as we understand it, is the correct way to backup clusters.

PJ

[bdufour]

i think he meant storage appliances and not backup servers (if you mean servers being backed up by 'backup server').

[TGacs]

This thread discusses the topic (AD vs. WG) further:

veeam-backup-replication-f2/veeam-on-wo ... 49090.html

[foggy]

i think he meant storage appliances and not backup servers

Correct.

But my question is: If the backup servers are not joined in the AD, then it will not be possible to do backups of AD objects like file- and SQL-cluster objects?

Not having Veeam B&R server joined AD domain doesn't affect your backup capabilities - you still can supply it with the required credentials to backed up servers.

[Gostev]

i think he meant storage appliances and not backup servers (if you mean servers being backed up by 'backup server').

That is correct, I did mean this in the context of that story specifically.

However, it was always a bad practice to have backup server joined your production domain - even well before the Age of Cryptolockers. This is because when your production environment goes down along with its domain controllers, it will impact your ability to perform actual restores due to the backup server's dependency on those domain controllers for backup console authentication, DNS for name resolution etc.

If you think more about this, it's really not that different from running your backup server as a VM on the ESXi host which VMs you're protecting. Likewise, when that host goes down, you won't be able to restore your production VMs to a new host - because your backup server is down as well.

Always remember the cornerstone of data protection solutions design:
"A data protection system must not rely on the environment it is designed to protect in any way."

[perjonsson1960]

I am not sure if I have received a reply to my question about failover clusters. For example, we have an SQL cluster with two physical servers. We created a protection group with Type "Microsoft Active Directory objects" and supplied the AD cluster object in the "Active Directory" section. And in the backup job the "Job Mode" is "Failover cluster", and we pointed it to the protection group. And this works very well. But is it possible to refer to AD objects in this way if the B&R server is NOT joined in AD?

[Gostev]

I don't see why not? At least there's certainly no requirement that a client that interacts with Active Directory must itself be running on a computer that is a part of the corresponding domain. Otherwise, for example, you would not be able to join new computers to the domain using System Properties dialog on the actual computer.

[LazyLoneLion]

You might join the server to AD but keep local "Administrators" group free from "Domain Administrators".

[bucoops]

I ended up joining our standalone host to the domain as if the PDC (not the only DC) rebooted mid-backup we lost connection to everything

[bdufour]

However, it was always a bad practice to have backup server joined your production domain - even well before the Age of Cryptolockers. This is because when your production environment goes down along with its domain controllers, it will impact your ability to perform actual restores due to the backup server's dependency on those domain controllers for backup console authentication, DNS for name resolution etc.

this is true - thats why its important to have a DC at your DR site. one of the best designs, according to my judgement, is having veeam, vcenter, and a full DC (not RODC) at your DR site.

[AlbieNorth]

Hi all,

Could someone provide a bit more clarification/detail on this as this has been a point of discussion at our office. Our Veeam servers are joined to our domain but I have wondered if they could not be pulled out of the domain for security purposes (so that access to them is only via local accounts on them that are not related in any way to any domain credentials). But the other IT person here who actually has set up and looks after Veeam says he needs to be joined to the domain because (as he says) "how do you backup the domain servers if you are not part of the domain). I have said that he should be able to supply domain credentials to "pull down" the data from the domain servers. Because I am not involved in setting up or running Veeam, all I can go on is what is said in the forums here.

Which is correct? Do the veeam servers need to be joined or not? Is there a white paper or tech note to show how to set this up if the veeam servers are not to be a part of the domain?

[bdufour]

it doesnt have to be - you can supply credentials to back up other servers on your domain. if you have a stand alone veeam server, removing it from the domain is rather easy. now if this server is hosting other services/applications that rely on your domain, you prob dont want to remove it from the domain. it really depends on your environment. if youre using separate accounts on your privileged accounts (domain admins) ect and restricting internet access to those accounts. i think youre kinda splitting hairs removing veeam from the domain. because if you start the remove veeam from the domain thing, you will need to create separate accounts for everyone using it, there will have to be some sort of password policy for these accounts, and it becomes a management headache. because when someone leaves - you need to disabled yet another account of theirs. that's one of the biggest benefits of AD and SSO is to make management easier. basically, if youre following a sound information security policy - i dont see the point. i work in the financial industry and go through multiple audits a year and never have they suggested removing a production server from the domain (unless its EOL).

[bdufour]

things ive learned from pen testing after 12 years of working in the banking industry (windows sec outside of the obvious...) -
enforce smb signing
enforce ntlmv2, refuse lm/ntlmv1
DISABLE ntbios and llmnr right now!(legacy name resolution protocols - not needed if dns is configured properly)
allow dns inbound/outbound from DCs ONLY
disable anonymous AD enumeration via gpo AND u need to remove everyone and anonymous from the builtin AD group - pre-windows 2000 compatible access to completely disable it...
separated accounts for privileged accounts with a fine grained PW policy - 15+ characters to break LM hashing algorithm
disable internet access to privileged accounts/service accounts (where possible, but u will see most of these service accounts dont need internet access..)
NEVER!! stayed logged into a privileged account longer than necessary (i cringe when i see admins, in other businesses, logged into several servers for no good reason.....)
use LAPS
i could go on and on...but these are some big ones in relation to protecting your privileged accounts and hashes.

[Seve CH]

Hi,

I have my Veeam servers in a separated VLAN, firewalled, without domain membership to limit the attack surface and dependencies. I do not like having a wanacry like worm hitting them or any AD/vCenter problem blocking Veeam access. I consider Veeam servers with storage like any storage array: restricted access, unbound from general infrastructure.

To do guest interaction with servers, there are the proxies without any storage. To do AD operations, there are specific credentials with specific rights you can use. We are taking backups and restoring SQL Always On clusters, failover clusters (MS, Linux and FreeBSD), Oracle Dataguard, Exchange availability groups, etc. without any problem.

Not being able to use AD accounts for single sign on accounts is a plus: I do not want anybody providing malware or keyloggers with access to the backup infrastructure because they were using their privileged account to install something in a server or PC. If they need to use Veeam, they will need their specific credentials to do so. It could be a mess to manage the in-out cycle of IT workers, but who really needs access to the backup infrastructure? Just a few. If you have more than just a few backup administrators, then you have other major problems. You can always keep a "rescue account" in a sealed envelope stored in a safe just in case.

Helpdesk uses Enterprise Manager in a domain member proxy, so they can still use their AD login to do their daily work and we can use AD groups to manage that, but they require absolutely no access to any Veeam server with backup storage attached to it.

Regards

[bdufour]

as far as management and compliance, you would need to have everything documented carefully, bc everything as far as the local security profile will need to be configured independently per system, as well as users, permissions, ect. if you have multiple veeam servers and users, this could become extremely cumbersome in larger environments. also forget about kerberos authentication with a workgroup server, you will be using ntlm (exclusively) and i hope youre enforcing ntlmv2 and refusing lm and ntlmv1....and you better have that documented.

'You can always keep a "rescue account" in a sealed envelope stored in a safe just in case' - that sounds like a compliance nightmare. i dont think i could even present that to a federal regulator.

helpdesk as far as im concerned doesnt need access to anything backup related, including enterprise manager...but i guess in some environments that may be normal.

outside of compliance and management - i do like the idea.