We begin a series of posts about aspects of securing Active Directory administration, created by Brian Svidergol. There will be three parts to this series (Part 1, Part 2, Part 3), each one dedicated to a specific problem around securing Active Directory administration and providing some thoughts for each of the areas:
- Principle of least privilege. While many administrators have heard this term and understand the basic concept, it doesn’t always correlate to the configuration of their environment. On the plate today – internal security incidents, examples of privilege escalation, and minimizing issues.
- Infrastructure considerations. Let’s talk about subnets for administration, administrative servers, and administrative client computers.
- Auditing/monitoring/alerting. Why you should audit success and failure, how monitoring plays into securing Active Directory administration, techniques to reduce alerting so that you take action when alerts come in.
Security is a big topic these days, especially in light of the recent attack on Target and other major retailers. Often, the focus after a major attack is securing IT systems and diving into corporate security policies to mitigate future risk. However, in my travels, I’ve found that there is one area that sometimes doesn’t get quite the attention it deserves – securing IT administration. For this blog, I’m talking specifically about administration of Active Directory including domain administration, object administration, and related administration for directory services related technologies.
Today you can learn about the way, in which the Principle of least privilege applies to the topic of Active Directory administration.
Wikipedia has a good introduction to the principle of least privilege. In the simplest definition, the principle of least privilege means that Active Directory administrators have only the minimum required permissions to perform their job tasks. Of course, the principle of least privilege extends to all of IT and beyond, but I am strictly covering it from an Active Directory administrative point of view for this blog post.
Internal security incidents. Look around on the internet and you’ll find incredibly different tales about how severe (or not) the internal risk is for IT security. I’ve seen reports that only 15% of security breaches occur from the internal network. I’ve seen other reports that show over 50% of security breaches occur from the internal network. Securing Active Directory administration isn’t really about where the incidents originate from or whether the malicious individual is an insider or an outsider. In many cases, it is highly likely that Active Directory is a key target. Because once a malicious individual owns Active Directory, the individual can begin owning a myriad of other systems by using privilege escalation. A few examples, including privilege escalation, are:
- Microsoft Exchange. While Exchange administration is sometimes performed by a totally different team than Active Directory administration, the permissions are doled out by using Active Directory groups. If you control Active Directory, you can add yourself to the appropriate groups and take complete control of the entire e-mail environment. That means access to the CEO’s mailbox, the ability to copy vast amounts of confidential mailbox data, the ability to take on the identity of a highly privileged IT user (such as a DBA with access to sensitive data) – just send an email as the DBA to gain additional access.
- Microsoft Lync. Same situation as Exchange. Role-based access built on Active Directory security groups. Add yourself to the appropriate groups and you can suddenly send an instant message as anybody in the entire organizations. You can hijack Lync meetings, redirect phone calls, and log conversations.
- File shares. The vast majority of file shares are secured by using Active Directory security groups. It isn’t uncommon for the most confidential and sensitive data to be stored on file shares – HR data, payroll data, corporate litigation data, and more. A malicious user that owns AD can use PowerShell to quickly grant himself access to every file share on the network.
You can see how things can quickly spiral out of control if a malicious individual owns your Active Directory! Here are some tips to help minimize issues and utilize the principle of least privilege in your AD environment. Look at all of the Active Directory delegation currently in place. I’ve found the following issues to be common delegation issues:
- The helpdesk personnel can reset the password for most or all of the Active Directory user objects. For example, if the helpdesk personnel can reset the DBA’s password, then effectively he can gain access to anything that the DBA can if so desired. Even if your helpdesk aren’t malicious people, outside attackers are always looking for the easiest way in. They don’t always go straight after a Domain Admin account. A phishing attack to a few helpdesk personnel may be all that they need. Recommendation: ensure that personnel that can reset only appropriate passwords (this will vary by environment). In some organizations, this means that the helpdesk can’t reset any IT passwords or executive passwords and those have to be handled by another team or a secure self-service method.
- Delegation to a single user object. In this case, IT administrators have only a single user object. The user object is used for IT administration, surfing the internet, and reading email. Luckily, this issue has been promoted extensively and some companies are taking action to separate administration accounts for general corporate usage accounts. If you haven’t already gone down this road, it is a huge win to do it. The phishing attacks, browsers exploits, and other attacks that are often used to break into networks, become much less effective (and often just an annoyance).
- Service accounts in the Domain Admins groups. This one really drives me crazy. I’m sure many of you feel the same way. And, like me, you’ve probably run across a situation where a network/DBA/application admin has requested a new service account and mentioned that the vendor said that the service account has to be a member of the Domain Admins groups. The first step in these situations is to ask for the official vendor documentation. Hopefully, you’ll be able to derive exactly what is required and delegate it appropriately using the principle of least privilege. Often, vendors don’t actually know exactly what’s needed and they go the lazy route – Domain Admin. This puts IT admins in the uncomfortable position of choosing to place the service account into the Domain Admin group or spending 50 hours of work trying to ascertain the minimum level of permissions needed. In any event, sometimes relying on IT forums will help because other admins may have already found the solution!
In the next post you will be able to learn more about infrastructure considerations.
