Active Directory (AD) is Microsoft's directory server — the software that ties servers, workstations, network components, and users into a unified whole. Keeping it secure and well-maintained is key to stopping attackers' lateral movement and credential theft.
Yet AD management and security are struggles for many organizations.
While some have said that Active Directory is dead, it remains a powerful part of most enterprise networks, even while the move to the cloud, services, and serverless applications has continued. Part of the Windows Server software suite, AD is nearly ubiquitous in on-premises network deployments and is expanding into cloud deployments through integration with Microsoft Azure, Google Cloud, Amazon AWS, and other public cloud instances. Though AD's use may well have peaked, it is far from an enterprise relic.
So what key practices will keep this not-relic from becoming a not-secure part of your network? While books could be (and have been) written about AD security, here are a half-dozen items multiple sources can agree on as key to a secure AD deployment.
Keep Your Eye on Accounts
AD can support more than a million accounts, but most criminals truly care about a relative handful: the accounts with the most privileges. In general, these will be accounts with local admin or domain admin rights. And nobody should be using these accounts to log in on a regular basis.
Those who are administrators should have two accounts: one with admin privileges and one without, as proposed in this 2018 Active Directory Pro article.
All of the day-to-day work required of an IT staff member should be possible with a "regular" account. The admin-privilege account should be used only to do specific tasks requiring the higher privileges; after the tasks are complete, it should be back to the "mere mortals" account.
There's one more account that bears mention: the Domain Administrator. This is the "god account" used only during initial deployment and then for disaster recovery. The best practice for this account is to give it a ridiculously long and complex password, secure the password in a safe, and then use the account only if things go disastrously off the rails.
Check Your Privilege
Within all accounts, even those of administrators, a "least privilege" model is the best practice, as Microsoft suggests. Every user account should come equipped with only those privileges required to do the job — no less, no more.
As part of this, account privileges should be reviewed every time an individual changes position or on an annual basis. "Privilege creep" is a real thing that is a real, huge, security vulnerability. Don't let it happen in your AD deployment.
One point of AD attack is the administrator account used to manage individual workstations. In many organizations that provision workstations from a single "golden" image, the administrator password can be the same for every computer in the fleet. An attacker who gains the password for one computer can control every workstation in the organization. At Black Hat USA 2019, Nikhil Mittal, principal trainer at Pentester Academy, discussed just such an attack surface in an interview with Dark Reading.
Microsoft's Local Administrator Password Solution (LAPS) is a tool, built on AD, that creates and manages the passwords for each workstation, storing them in AD where an administrator can access them when required. LAPS makes sure that the password for each workstation is unique, limiting the damage that can result from compromising any single machine.
Guard Domain Controllers
Domain controllers are the servers where the actual databases for the directories are stored. A compromised domain controller (and there can be several levels of domain controllers in a large network) can open the entire network — and every workstation and server — to breach.
If domain controllers have been set up to allow access via external link — which can be justified in order to make remote management and problem solving easier — then they are much easier for a criminal to attack. To prevent this, Microsoft suggests that domain controllers should be accessible only via single, local machines. It makes late-night or weekend problem solving harder, but the trade-off for security is a best practice for AD.
Watch the Watchers — And Everyone Else
IT staff members understand the network as it existed on the day it was deployed, but attackers win by understanding the network as it exists today. IT security staff can prevent this route of attack by constantly monitoring the network.
Never let someone outside the organization know the network better than you. In an interview at Black Hat 2017, Ty Miller, managing director, and Paul Kalinin, senior security consultant, from Threat Intelligence Pty. Ltd discussed the complicated nature of this monitoring and some of the consequences of not staying on top of a network's activities.
For example, Miller and Kalinin explained, this failure to monitor could make it possible to create an AD botnet. Further, detecting such a botnet based on simple metrics like network performance would be almost impossible.
So what kinds of things should be monitored?
Systems should be constantly monitored for their state of patching and updating. User accounts should be monitored for excessive login attempts that could indicate an attempted hack. The network should be monitored for unusual traffic or traffic destined for unusual recipients. Part of that, as Microsoft guidance explains further, is understanding what usual traffic looks like, especially from highly privileged users.
There's a long list of "should be monitored for …" but it all boils down to not allowing anyone to have a more accurate picture than your staff of what's happening on the network.
Upgrade from Passwords
This is a simple user training step that requires no additional hardware or software: Teach users to ditch passwords in favor of passphrases. An easy-to-remember phrase can make a user credential that is virtually impossible to crack via brute force or guessing.
So what's the difference? A strong password might look like, "Xfj45!h4?HPS470*." It's strong, but impossible for most humans to remember. It begs for either a password manager or a sticky note stuck to the user's monitor.
A passphrase, on the other hand, might be,"ILovethePizzaatBobby'son34thSt." That's strong, long, and memorable. Moving to passphrases shouldn't require much training or additional hardware or software — it's the kind of best practice that every organization should be able to get behind.