We continue the series of posts about aspects of securing Active Directory administration, created by Brian Svidergol. There are three parts to this series, each one dedicated to a specific problem around securing Active Directory administration. The first part, focusing on the Principle of least privilege, can be found here. Today you can learn about infrastructure considerations, such as subnets for administration, administrative servers, and administrative client computers.
Sometimes, simple ideas are quite effective in a security strategy. Consider a common online banking recommendation – only bank online from a single computing device. Some people may take that as an annoyance when first thinking about it. But thinking a little longer, most people realize that the recommendation is sound. Banks have built in security monitoring to watch for online banking logons from unknown computing devices (in addition to unknown locales and other criteria). Banks will typically prompt for an additional authentication factor when logging on from an unknown device or location. But if it happens to meet their monitoring thresholds such as logging in from two different countries within an hour, automated tasks kick in to mitigate risk. I want to talk about 3 areas of the infrastructure that should be considered when securing Active Directory administration.
- Subnets for administration. Similar to online banking, organizations can reap benefits from centralizing administration to specific subnets. Thus, when administrative connections are attempted outside of the specified subnets, notifications are sent out to administrators. While the concept is simple, the execution is difficult. One major difficulty is web-based administrative interfaces which operate on TCP port 443 – blocking this traffic from specific subnets to other specific subnets requires a lot of man hours. There are immediate benefits when using administrative subnets though. One benefit is alerting – if an RDP connection is attempted to a domain controller from a non-administrative subnet (user subnet, wireless subnet), it is an immediate red flag and something to follow up on. For many organizations, an RDP connection to a domain controller can be performed from anywhere on the network. Even worse, in my travels I’ve seen organizations that allowed RDP connections to their domain controllers from the internet! Another benefit of administrative subnets is that they can be locked down by using secure subnets (port security), two-factor authentication, and other techniques. The lockdown can occur without too much fanfare. Compare that to locking down a user subnet where users will be up in arms! In the next section of this blog, I’ll talk about monitoring and alerting which tie into administrative subnets.
- Administrative servers. Even if you can’t use dedicated subnets for administration, using dedicated administrative servers is the next best thing. For organizations that can use dedicated administrative servers and administrative subnets together, even better! So what do administrative servers get you? Like administrative subnets, you can deploy additional security in and around the servers. I’m talking two-factor authentication or certificate authentication, high security GPOs, standard user accounts for administrative server authentication, and specialized monitoring and alerting which I’ll talk about in the next section of the blog. Administrative servers also contain all of the tools that the administrators need which can help standardize all of the administrators on the same toolset and same versions of tools.
Administrative client computers. I’ve talked with a lot of people about how they and others in their organizations perform Active Directory administration. More often than not, the responses have all been the same – administration is performed from assigned client computers. The assigned client computers are used to work with e-mail, browse the internet, and perform administrative duties. Quite convenient, no doubt. Even more convenient if you have a single AD user account that you use for everything! But we aren’t talking about convenience today! We are talking about security. And those two things often don’t go together! With a single client computer and a single user account, an administrator and his computer become a prime target for many types of attacks including phishing attacks. If the administrator’s computer gets owned, the attacker has administrative access to everything that the administrator does. And even better, he has all of the tools installed on the computer, the cache of the administrative tools (RDP connection info, FTP info, etc.). It is immediately clear how risky it is to operate on a single client computer with a single AD user account. The fix? Use a secondary user account for administration. Use an administrative client computer (likely a VM in a VDI environment) for administration. In a perfect world, have a second user account and an administrative client computer. Similar to administrative servers, administrative client computers can be locked down, have two-factor authentication, and be part of an enhanced monitoring and alerting infrastructure. While I see separate administrative accounts widely suggested in IT, I don’t see administrative client computers as widely used.
