|
In the last article, there was a brief introduction to Active Directory as it relates to LDAP, NT 4 directory services, and a few other things. Understanding the structural and syntactical layout of an LDAP/AD database was also covered in brief. Lastly, some general thoughts were given out about the implications of making a computer network as integrated, reliant, and controlled by a massive directory service like AD. In this article, we'll begin to approach AD security implications in a more technical manner.
The scope of this particular article is largely around accounting, permission, enumeration, and logging issues. This article does not cover default DNS settings.
This article begins considering AD security with the installation of the first Win2K domain controller in an AD network: the root through which the rest of the AD tree/forest will grow. Most networks with AD in them are still in large part based on NT 4 directory services. As such, the AD network will be installed with permissions compatible with pre-Windows 2000 networks. Herein, we discover our first major security implication. Selecting that option grants most of the information gathering options that were available on NT 4 networks when an attacker established a what's been known as a null or IPC$ connection. This connection allows an attacker to gather all sorts of information about users on the domain and may also include listing which services the server has available, which ones are running, descriptions of those services, and a host of other things. In short, installing in non-native mode will bring back security issues that might have been thought lost by moving to Win2K. Be aware of this when installing Active Directory in non-native mode. (As a note, NetBIOS is still active on any machine, including domain controllers, in a default Win2K install).
Another thing to be aware of is that logging may not be set up the way you may have hoped. For instance, by default, security logging is not enabled?at all. Good login, bad login, service lookup, none of these things are logged. Some readers with administrative experience will remember that security logging is not turned on by default in NT 4, and so will not consider this an issue, rather, they will consider it as something that should be known in advance by anybody who is going to set up a domain in the first place. In the case that you are not aware, make sure that security logging is turned on in your policy.
While on the topic of policy, the question may arise around which events to enable, and when one should enable successful and unsuccessful audits. One item that should be checked, at least for failures, is Directory Service Access. Administrators might, for various reasons, decide to keep this particular policy at default settings. This is not a wise idea. If logging is not enabled for Directory Service Access, any attempts to alter the directory will not be logged. If you don't understand the meaning of this, consider the following:
The directory is a lot like any normal windows registry, except that the directory exists on the network and a windows network depends on the directory to function well. Any amount of mischievous tweaking with a normal windows registry can render a system unusable. Following that line of thinking, any amount of mischievous tweaking with the directory can render a network unusable. Hence, you probably want to be aware in the case that a user is trying to alter objects in the directory that he shouldn't be. We'll touch more on the topic of directory fragility in the fifth article in this series, but for now, keep that concept on the back burner.
Another thing that might be cause for concern, and is not "point and clickably" easy to prevent (a workable solution is not present within this article) is that by default, authenticated users can view a number of things within the directory which they should not be able to view in a secure environment. For instance, users can view the domain configuration (DC=domain, DC=com), the schema (CN=Schema, CN=Configuration, DC=domain, DC=com), the configuration naming context (CN=Configuration, DC=domain, DC=com), and another area of the directory that does not have an official name, to my knowledge: (CN=System, DC=domain, DC=com). In the next few paragraphs, we'll consider the significance of each of these sections of the directory.
We'll start with domain configuration. I prefer Microsoft's LDP tool as a means for browsing the directory. Here, we have attached to the tree with the user joebob1. We opt to view the DC=dgs, DC=com portion of the directory. These are the options presented to us.
It would be fair to say that there are at least a few things within this context that would be considered sensitive material. At this point, not only are these things sensitive material, they are sensitive material stored in a nicely centralized, organized, viewable container. For example, from here, we can list all domain controllers. As you can see below, our domain controller, DGS-ACTIVE is listed, along with some other sensitive information (for instance, drive and path where sysvol is located on each particular domain controller, such that an attacker has information available on where he needs to place files to be replicated across the domain). Once this information has been obtained, these servers can be targeted individually if desired, as they are all listed within DNS.
Continuing on, we'll move to the schema. A screenshot has not been taken of the schema because it's too large to fit in this document (there are hundreds of entries). However, for those that don't know what the schema is, I will offer a brief explanation.
The schema is a section of the directory that defines what else can be stored in the directory. You might consider it as a global inventory system of sorts for the directory. Whatever is listed in the schema, how it is listed, and the information allowable for each listing, as well as the formatting for that information, is what is available to be put into the rest of the directory. For example, Canonical-Name is one of the listings in the schema. Having Canonical-Name listed in the schema means that Canonical-Name can and may be listed elsewhere in the schema. Removing Canonical-Name from the schema means that the rest of the directory can no longer support the attribute Canonical Name. (Some of you who have a penchant for seeing the evil and nasty possibilities of manipulating such things, or just flat out removing them probably have wicked grins on your faces right now).
Those of you that learned anything about the active directory schema probably remember that one of the first things you learned about the schema is that manipulating the schema can lead to very hazardous consequences. Before getting too carried away with concern, remember that your average user only has read-access to this information (all of these contexts only have read access-available to them), so he/she can't manipulate it at this point (only schema admins can manipulate it). Being aware of each of these pieces of information and having access to see exactly how each of these things is configured is the first step in gaining access to them, however. It would be better if these things were not viewable in the first place.
One other thing (of possibly many things) to be concerned about with being able to view the schema depends on whether or not the schema has been expanded to suit new features or applications. Be aware that if those expansions have not had security-attention paid to them, they may become very critical pieces of information picked up on the road to compromising your network? as has been iterated before; be careful what you do with your schema. On to the configuration naming context!
The configuration naming context is one of the most critical objects in AD. It controls and stores a number of things; but perhaps most importantly, it controls how Active Directory "lives" on the network. By that I mean that it stores the information and configuration for how the directory is replicated throughout an AD network. Here's some of the information available to any domain user by default (note, the screenshot doesn't cover everything here, but would go for pages if it did):
Lastly, RDN System is another section of the directory that exposes critical information. Due to size constraints for this article, I won't show a screen shot, but I encourage you to run the LDP tool (or some other LDAP client of your choosing) against your directory and verify these details for yourself. A couple of particularly interesting sections to look at are IP Security, MicrosoftDNS, and File Replication Service.
Hopefully, this article has been enlightening to you and you'll continue reading the series when the next article, Understanding SASL, Kerberos, LDAP v2 & v3, and What They Have to Do With Active Directory Security is published. All of the topics in the next article could have books dedicated to them. We'll just touch on some of the key topics as they relate to Active Directory. I'm sure that it's already clear that there's a lot to be learned and to be considered about the relative security of this new technology.
To read An Audit of Active Directory Security, Part Three: Understanding LDAP, SASL, and Kerberos in the Context of AD Security , click here.
|