Offline Domain Controller - Security Strategy

[didentity]

Hi

Wanted to start a discussion and pick thoughts on an old strategy of keeping a domain controller offline (disconnected from network or turned off) for 2-4 weeks as a backup apart from taking daily backups. Some choose delayed replication but it has its own drawbacks. What do you think?

[#2]

@didentity 

Not something I'd consider - especially in a larger environments.

If I look at it from a data loss perspective, I'd be looking to the AD Recycle Bin in the first instance.

If it's serious data loss, destructive service configuration or security compromise, the primary point of reference is still going to be a known good back-up coupled with an authoritative restoration (plus some other actions in the compromise scenario), to which the "offline" domain controller doesn't bring any real value.

On compromises, given how hard it can be to actually detect them in the first place, you also run the very real risk that the "offline" domain controller only captures the issue, preserves it and re-introduces it once reconnected to the forest (you'd have to have seriously bad luck for this to transpire, but it's possible).

On the "not serious" level, you could also run into replication conflicts, but that's probably not worth speaking to (as it's not that likely) when measuring against the big ticket considerations.

Unless the back-ups routinely fail ten to twenty day in a row, I can't see the benefit (again, for large environments).

On smaller environments, there's some technical merit but I haven't come across anyone (large or small) in recent times that would accept an RPO of ten to twenty working days. So, there's that business element to consider, too.

Cheers,

Lain

[#3]

Also interested in thoughts on this and would also go to the AD Recycle Bin to recover from inadvertent deletions. So what are we protecting against. If a single DC has failed then you would just build a new one and let it sync. So we must be talking about forest wide AD corruption and so thinking about an authoritative restore. Now we could do an authoritative restore and let it propagate back to all the existing DCs, but I'd be concerned that the cause of the corruption in the first place was one of those DCs so it is just going to happen again. The only way to be sure is to remove all the existing DCs in which case a non-authoritative restore is going to be the starting point, but that is exactly what the offline (and ideally offsite) domain controller is giving you. If the offline DC is compromised with the same malware that caused the issue then likely all the backups are too. So I guess the question boils down to whether it is easier to do backups and then have to restore, or to go through the faff of reconnecting the offline DC periodically to let it resync and have all the replication monitors always reporting a failure for that DC. I think probably backups, but then I also think that your probably knackered anyway if you need to use them, in which case why bother? I do think an offsite online DC is an absolute must have so all of this assumes we aren't talking single site. Would a two year old AD be useful to use as a recovery point (or something likely before the AD was compromised)? Well maybe it would be better than nothing. Like everything else, you really need to work out what you are hoping to protect against and do your FMEA. I think I've talked myself into monthly backups and absolutely 321.

[#4]

@ianmidg An offline domain controller is a bad idea, first because Active Directory hasn't been designed for this purpose. When using a hammer on something else than nails, bad things will happen.

You got Active Directory Recycle Bin for objects recovery. You got DRP for disasters. Those are the right tools for recovery needs.
You can't keep a domain controller offline for too long - tombstone will kick in. Restoring a offline DC within tombstone will still cause tons of issues - GPO, accounts,  passwords, tickets etc... not counting issues during normal operations, precisely because it's offline.

[#5]

@Alban1998 - can you cite something from Microsoft that states it is a bad idea? The fact that tombstones last for 180 days suggests AD has been designed to accommodate DCs being offline for more than a week or so. Were you involved in the original design? I'm trying to work out whether this is your personal opinion or something that can be backed up with best practice from Microsoft.

[#6]

@ianmidg This is my personal opinion after 12+ years of practice. But it doesn't mean it's based on thin air either.
You're welcome to read Microsoft documentation, MS Directory Services (aka AskDS) blog, or even consult Microsoft PFE about it (I did all of that). There is a lot of official guidance and best practices on Active Directory resiliency.
And no, tombstone hasn't been created as a recovery tool (and wasn't always 180 days btw) - neither additional domain controllers (which improve resiliency, but do not replace a DRP).
You are trying to fit a 20 years-old design on your idea to make your point - but it doesn't work like that.
Nobody does what you are trying to do. There are reasons for it. One of them is an offline domain controller is a management/security/day-to-day operations nightmare.

[#7]

Lol - we can all quote our experience. I have 22+ years of practice, started with NT 3.5 and got my MCSE+I in 1999. I was interested in whether there were any real reasons for not doing what the OP suggested not just opinions. It isn't my idea or my point. You have no idea whether I am advocating this or not, but it would be useful to get some objective reasons so that other people finding this could be better educated rather that just waving our hands in the air and making claims without pointing to documentation . I would also suggest that you have no idea of what tombstones were created for as you weren't in the original design team (and nor was I). I prefer backups for a number of reasons but the idea of an offline DC is worth investigating, much like an offline root CA, which I guess would also come under your management/security operations nightmare heading.

[#8]

@ianmidg Read all posts above yours, check the links I provided you and you'll find some real reasons why it's a bad practice to do this.
Offline CA root has its own security challenges, but it's not domain-joined, so all the issues related to an offline domain controller doesn't apply there.

[#9]

No help at all.

[#10]

@ianmidg 

Keeping an offline DC is a beautiful idea and you can easily schedule it for updates and limit its replication partners so that it is "isolated" from the rest of the network until you put it into service.

The good news is that when you need it, you won't require backups or any time-wasting measures that stress you out when the users lose their tempers because they can't access your domain or forest resources. 

Of course, there are many other ways to restore your domain controllers in the event of total catastrophe, but this is definitely one of the methods you should consider in your DRP strategy and I applaud you for not giving in to nay-sayers because this method works too.

If you want to explore some of the ways to implement the strategy please DM me and I will send you a few different approaches to achieving it with varying degrees of complexity and fault tolerance.

If you keep an open mind and continue being creative in your approach to security you will bend the risk-reward ratio in your favor. Professional interlopers are risk averse and always consider the ratio when they attempt an infrastructure breach.