Active Directory Backup

Backup is another Active Directory task that used to be a simple routine based on the 3-2-1 principle (three copies of data on different media, one offline). This backup could overcome accidental deletion, database corruption, as well as meet compliance and data retention requirements.

Admins could restore a full domain controller server or only the system state. Then, someone invented ransomware. To say the least, things got kicked up a notch, with the possibility that attackers might encrypt the Active Directory database or domain controllers.

Old world backup then became, in technical terms, toast. Why? Because ransomware has probably targeted those backups too.

Today, the only defense is to invest in full disaster recovery, including not only offline and immutable copies of data but, possibly, isolated and air-gapped repositories.

Read more:
Ensuring access security with the UserLock backup server

Active Directory default security settings

Security defaults are where you start from, but not where you end up. And, as in life, where you start from still matters. Active Directory has a small problem with this – the whole question of knowing exactly where that starting point is.

After all, admins rarely use Active Directory in its default state. Almost always, someone has already changed most of these settings. And almost always, that person of course is no longer with the company.

For the record, Active Directory security defaults are based on a baseline of group permissions and access levels for domain users, admins and guests, and settings that dictate things like minimum password length and lockouts. In truth, it’s less about which default security settings need to be tweaked (because they all do).

Start by carefully locking down the most privileged accounts (Enterprise administrators, schema administrators, domain administrators, and administrator groups), creating a virtual machine infrastructure that limits the effect of a single server breach.