AD Audit by Symantec

8/3/2019 AD Audit by Symantec

1/20

Introduction

Anyone familiar with security architecture of the Windows NT family of operating systemsknows that one of the biggest threats to the structure is in the NetBIOS services. Such threatswere discovered early on in the existence of NT in both versions 3 and 4. Since then,

administrators have learned a few things about how to harden an NT host to protect it fromnasty NetBIOS information-gathering tricks. Now there's a new Microsoft operating systemon the block, with new directory services and authentication mechanisms, namely, ActiveDirectory and a "Microsoftized" version of the Kerberos authentication system respectively.

Administrators with security concerns might be glad that NetBIOS and the old NT domainmodel are disappearing. They might be thinking, "phew, no more NetBIOS to worry about!"They may be anticipating that there will be no more null session holes and concerns, no moreinsane L0pht Crackers, no more master browser disputes, and no more quick easy dumps ofevery critical server on a network by the service they provide. Administrators may think theyare safe now, right? Wrong! Issues like these still exist, they've just changed according to the

new architecture.

In fact, unless NetBIOS is explicitly turned off, it still runs on a default install of Win2K.Unfortunately, while one might think the new technology is more secure than earlier versions,it's still going to have to be tested in the real world before some very big, nasty issues arediscovered, publicized, patched, and people are educated about them. Until then, users may beresting on a lot of yet undiscovered bugs. These bugs may prevent people from embracingActive Directory, despite all of its wonderful features.

This article is the first in a series that will discuss some potentially major security issues thatmay exist in the implementation of Active Directory. As Active Directory is a very large,complicated technology, these articles will come nowhere near reviewing the entirety of thesubject. This installment will offer a brief overview of Active Directory, as well as a veryintroductory look at some of the security issues surrounding it. The next few articles willdiscuss the following subjects:

Understanding the Security Implications of Active Directory Default Settings Understanding SASL, Kerberos, LDAP v2 & v3, and What They Have to Do With

Active Directory Security The Configuration Naming Context (Keys to the Kingdom), Some Caveats, Some

Issues

A Theoretical Attack on the Multi-Master Replication Scheme in a Massively ADEnabled Network in the Enterprise (a.k.a. what the disgruntled employee/ex-employeecould do to really screw up an organization.)

This article is targeted primarily at readers who are running Active Directory right now, orwho are considering migrating at some point in the near future. In order to better understandthe issues that will be discussed throughout this series, it may be helpful to first talk aboutsome basics of Active Directory and the technology that it is based on. In some cases, theissues to be discussed are more to, or are inherited by the technology that most very highspeed network directory services (such as AD) rely on these days: LDAP.

LDAP


2/20

LDAP stands for Lightweight Directory Access Protocol. It is based upon X.500 DirectoryAccess Protocol technology, but is much smaller and faster, with a lightened feature set thatallows for it to be run and scaled on most hardware. LDAP is the basis for numerouscommonly-used systems, and has quickly become THE technology for high speed, directoryenabled programs and networks: Novell NDS (in recent versions) is based on LDAP as are

many implementations of UNIX workgroup technology, to name but a few.

LDAP v2 has been fairly prevalent in the past and many systems still run on it. LDAP v3 nowexists as well and has many improvements over LDAP v2, some in the security realm, othersin the schema and performance realm. Active Directory is compatible with both versions ofLDAP, but only in certain distributions. While there is much discussion and dispute overexactly which distributions will and won't work with AD, this series won't comment on thatissue other than the discussion of LDAP v2 integration with AD and the security thereof.

As Active Directory is a very large, complicated technology, this series cannot offer anoverview of the entire technology (For a more in-depth overview, please seeSupport

WebCast: Windows 2000: Directory Services, Part One.) For readers who are not currentlyusing Active Directory, but who are considering migrating to it, the following section willoffer a brief overview of a dump of an Active Directory tree for a hypothetical domain name,dgs.com. It is the result of a connection event (just a connection, not a bind or anauthentication, a distinction that will become important to understand later) to the ActiveDirectory "root" server for dgs.com using Microsoft's excellent ldp.exe tool. For reasons ofbrevity, I haven't included the whole dump, only a few select portions of it for now.

Established connection to active. Retrieving base DSA information...

Result : (null) Matched DNs: Getting 1 entries: >> Dn: 1>

currentTime: 6/28/2001 20:32:48 Pacific Standard Time Pacific Daylight

Time; 1> subschemaSubentry:CN=Aggregate,CN=Schema,CN=Configuration,DC=dgs,DC=com; 1>

dsServiceName: CN=NTDS Settings,CN=DGS-ACTIVE,CN=Servers,CN=Default-First-

Site-Name,CN=Sites, CN=Configuration,DC=dgs,DC=com; 3>

namingContexts: CN=Schema,CN=Configuration,DC=dgs,DC=com;

CN=Configuration,DC=dgs,DC=com; DC=dgs,DC=com; 1>

defaultNamingContext: DC=dgs,DC=com; 1> schemaNamingContext:

CN=Schema,CN=Configuration,DC=dgs,DC=com; 1>

configurationNamingContext: CN=Configuration,DC=dgs,DC=com; 1>

rootDomainNamingContext: DC=dgs,DC=com; information removed here 1> highestC

serverName: CN=DGS-ACTIVE,CN=Servers,CN=Default-First-Site-Name,CN=Sites,

CN=Configuration,DC=dgs,DC=com; 1> supportedCapabilities:

1.2.840.113556.1.4.800; 1> isSynchronized: TRUE; 1>

isGlobalCatalogReady: TRUE;

Here's a quick legend to help you understand the acronyms used:DN = Domain NameDC = Domain ControllerCN = Canonical Name (or short/easy name)NTDS = NT Directory ServicesUSN = Updated Sequence NumberSASL = Simple Authentication & Security LayerGSSAPI = General Security Services APIGSS-SPNEGO = General Security Services - Service/Security Protocol Negotiator

DN = Distinguished NameRDN = Relative Distinguished Name
http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000


3/20

Those of you that understand LDAP or have worked with Novell NDS will see that some ofthese names look familiar. For those of you that don't, or those of you that don't understandActive Directory in general. I recommend that you visit Microsoft's knowledge base or referto theSupport WebCast: Windows 2000: Directory Services, Part One.

Let's start from the top of the dump: the name of the server is 'active.' The name 'active' is onethat I have included in my host file for quick entry. The actual name of the server is DGS-ACTIVE. Hence we actually have a connection to DGS-ACTIVE. The next entry states thatthe base information for the directory services agent is being retrieved. A receipt of a nullsignifies the completion of that run, and then we get a match of the domain name for the entryof DC=dgs,DC=com. Those of you who are familiar with Netware (which is also based onLDAP) might be seeing something that looks familiar. This information signifies that thisserver is the root server for the dgs.com domain. This concept ties directly to DNS, wherethere are also root name servers. In DNS terms, you might consider that this server is knownas .dgs.com (with and underline on the . to signify root status.)

Next, a time stamp is attached to the report and we get the first pieces of information aboutthe actual server and tree. A standard response is included in the next entry, in which theaggregate information for the Schema Configuration for the DGS.COM tree is shown. Thelast line for that entry is the directory service type that will be providing this information.Theoretically, this entry could be LDAP, or NDS, or NTDS, or NTDS2. However, since weare connecting to an AD server after a default installation, the only entry we should expect tosee is NTDS.

Next, we move on to the general settings for this particular tree. The numbers that start eachentry denote that there is only one piece of information listed in the directory for each entry.You'll note that later on in the list, there is a '3', which means that the naming contextsavailable are each of the entries separated by a semi-colon, namely:'schema,configuration,dgs,com', 'configuration,dgs,com', and 'dgs,com'. If you're wonderingwhy I separated the CNs by commas, it's because that's how one separates CNs in asyntactically correct manner. The next few entries should logically fit according to their labelsbefore the DN is given.

What is a DN? A DN is simply a linking of all CNs and DCs relative to an entry. Forexample, one might call the c:\winnt\system32 directory the 'system32' directory and otherswould probably know what was being referred to. This naming convention would be referringto the c:\winnt\system32 directory name via its RDN, or Relative Distinguished Name, which

is okay because most admins know that the system32 directory is commonly relative to thec:\winnt directory. If one wanted to be more specific, he or she might use the DistinguishedName, which means they would need to call the directory c:\winnt\system32.

Active Directory and Security

Among the advantages of implementing Active Directory on a network are the features andfunctionality it allows: it makes user administration, security policy administration, Exchangeadministration, and a host of other things much easier, efficient, and less time consuming.However, as alluded to in the introductory section, security concerns must be taken intoaccount? Administrators must consider that with a massive directory service (such as AD)

running on their network, with the power and flexibility that it provides, much more detail isgoing to needed in the security policy, both in technical and personnel sections. As well,
http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000http://support.microsoft.com/servicedesks/webcasts/wc011300/wcblurb011300.asp?LN=EN-US&SD=gn&FR=0&qry=understanding%20active%20directory&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000


4/20

incident response, the monitoring of both performance and security will also need to be takeninto account in order to protect the information systems of the organization. In an ADnetwork, in order to function, everybody has to connected in order to operate properly. Thismeans that all users are exposed to potential propagation of viruses, trojans, and worms, aswell as other security threats.

Any administrators who have used MS SMS products have probably made the humbling errorof selecting the wrong group of PC's to receive an immediate package roll-out. Some mighthave selected the wrong group with a title like "Entire Enterprise NT 4.0 Group." Some mighthave seen all of their systems reboot and start installing an incompatible package that wouldblow a number of machines away. Meanwhile, they have realized this and started scramblingto unplug the SMS servers from the network in a mad panic. Readers who have made thismistake realize that it was an innocent, dumb mistake. But imagine what could have beendone if this mistake was committed intentionally by an intruder who meant to do harm. As weshall see in subsequent installments in this series, Active Directory can be used towardssimilar, broadly effective ends.

Conclusion

It is hoped that this article has provided readers with a bit of an understanding of some of thesecurity issues raised by Active Directory; however, it was only intended to serve as anintroductory overview. In the next article, "Understanding the Security Implications of ActiveDirectory Default Settings", we will begin to attempt to break down some of the many issuesto face with AD , considering AD at its point of default inception on a network, includingsome information that will lead into the following article on AD management andauthentication mediums.

In the last article, there was a brief introduction to Active Directory as it relates to LDAP, NT4 directory services, and a few other things. Understanding the structural and syntacticallayout of an LDAP/AD database was also covered in brief. Lastly, some general thoughtswere 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 approachAD security implications in a more technical manner.

The scope of this particular article is largely around accounting, permission, enumeration, andlogging issues. This article does not cover default DNS settings.

This article begins considering AD security with the installation of the first Win2K domaincontroller 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. Assuch, the AD network will be installed with permissions compatible with pre-Windows 2000networks. 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 whenan attacker established a what's been known as a null or IPC$ connection. This connection


5/20

allows an attacker to gather all sorts of information about users on the domain and may alsoinclude listing which services the server has available, which ones are running, descriptions ofthose services, and a host of other things. In short, installing in non-native mode will bringback security issues that might have been thought lost by moving to Win2K. Be aware of thiswhen 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, servicelookup, none of these things are logged. Some readers with administrative experience willremember that security logging is not turned on by default in NT 4, and so will not considerthis an issue, rather, they will consider it as something that should be known in advance byanybody 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, atleast 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 isnot enabled for Directory Service Access, any attempts to alter the directory will not belogged. 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 thenetwork and a windows network depends on the directory to function well. Any amount ofmischievous tweaking with a normal windows registry can render a system unusable.Following that line of thinking, any amount of mischievous tweaking with the directory canrender a network unusable. Hence, you probably want to be aware in the case that a user istrying to alter objects in the directory that he shouldn't be. We'll touch more on the topic ofdirectory fragility in the fifth article in this series, but for now, keep that concept on the backburner.

Another thing that might be cause for concern, and is not "point and clickably" easy toprevent (a workable solution is not present within this article) is that by default, authenticatedusers can view a number of things within the directory which they should not be able to viewin 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), theconfiguration 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 ofthese sections of the directory.

We'll start with domain configuration. I prefer Microsoft's LDP tool as a means for browsingthe directory. Here, we have attached to the tree with the user joebob1. We opt to view theDC=dgs, DC=com portion of the directory. These are the options presented to us.


6/20

It would be fair to say that there are at least a few things within this context that would beconsidered sensitive material. At this point, not only are these things sensitive material, theyare sensitive material stored in a nicely centralized, organized, viewable container. Forexample, 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 anattacker has information available on where he needs to place files to be replicated across thedomain). Once this information has been obtained, these servers can be targeted individuallyif desired, as they are all listed within DNS.

Continuing on, we'll move to the schema. A screenshot has not been taken of the schemabecause it's too large to fit in this document (there are hundreds of entries). However, forthose 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 islisted in the schema, how it is listed, and the information allowable for each listing, as well asthe 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-Namelisted in the schema means that Canonical-Name can and may be listed elsewhere in theschema. Removing Canonical-Name from the schema means that the rest of the directory canno longer support the attribute Canonical Name. (Some of you who have a penchant forseeing the evil and nasty possibilities of manipulating such things, or just flat out removingthem 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 leadto very hazardous consequences. Before getting too carried away with concern, remember that


7/20

your average user only has read-access to this information (all of these contexts only haveread access-available to them), so he/she can't manipulate it at this point (only schema adminscan manipulate it). Being aware of each of these pieces of information and having access tosee 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 theschema depends on whether or not the schema has been expanded to suit new features orapplications. 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 compromisingyour network? as has been iterated before; be careful what you do with your schema. On tothe configuration naming context!

The configuration naming context is one of the most critical objects in AD. It controls andstores 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 informationavailable 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. Dueto 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


8/20

these details for yourself. A couple of particularly interesting sections to look at are IPSecurity, MicrosoftDNS, and File Replication Service.

Hopefully, this article has been enlightening to you and you'll continue reading the serieswhen 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 couldhave books dedicated to them. We'll just touch on some of the key topics as they relate toActive Directory. I'm sure that it's already clear that there's a lot to be learned and to beconsidered about the relative security of this new technology.

This article is the third in a series devoted to discussing security issues surrounding ActiveDirectory, also known as AD. Thefirst articleoffered a brief overview of Active Directory.Thesecond articleoffered an overview of the security implications of AD's default settings.This article will offer an overview of the relationship between LDAP, SASL and Kerberos,and examine what they have to do with Active Directory Security.

Some Feedback From Last Time

Before I start the article, I'd like to include feedback that was received from one of the readersof the second installment in this series. I feel that it is timely to the subject and might makethose that deploy Active Directory consider whether or not connection to the Internet is anissue. I'd originally written this series of articles (especially the upcoming Part Five) with thethought in mind that most attacks on AD from within the organization or company. However,as this message illustrates, it may be possible to exploit the things that have been mentioned inthe two previous articles from outside the network. Readers who have made the error ofmaking their AD available at the perimeters of their networks should take caution from thewords of this reader.

#/snip When it comes to AD and security I think that the

problems already have started to grow. Both from performing security

investigations for our clients and from analyses of our firewall and

network monitoring logs we have seen that the hunt for finding ADs and

trying to exploit them already has begun. In fact, at least here in

Sweden, I'm horrified to see the number of badly (read: default)

configured w2k/AD servers that are out there. Another obstacle is that

some firewalls seems to be configured to let port 389 through since

some companies have been using LDAP-directories in a rather public

manner. When they install boxes that makes use of AD's, the forget to

check their firewall(s). Running the following small

script (on a Linux box, similar scripts can probably easily be made

for MS systems as well) with a host list generated by nmap or similar

scanners that has been told can for port 389 will get you incredible

amounts of AD-related information. #!/usr/bin/perl #

Replace with nmap scan for port 389, then # read list of hostnames

from a file, cmdline etc. # and read it into @hostlist foreach

$host (@hostlist) { open(CMD,"|ldapsearch -s base -b "" -h $host *=*

> $host.ldif"); close(CMD); } We've already seen

several probes which seem to utilize such a principle. #/snip

The meaning of this message should be apparent, especially if you've read the past twoarticles in the series. It is also a perfect lead-in to this article because it notes one of thecornerstones of AD technology: LDAP.

LDAP
http://www.symantec.com/cgi-bin/infocus.pl?id=1292http://www.symantec.com/cgi-bin/infocus.pl?id=1292http://www.symantec.com/cgi-bin/infocus.pl?id=1292http://www.symantec.com/cgi-bin/infocus.pl?id=1293http://www.symantec.com/cgi-bin/infocus.pl?id=1293http://www.symantec.com/cgi-bin/infocus.pl?id=1293http://www.symantec.com/cgi-bin/infocus.pl?id=1293http://www.symantec.com/cgi-bin/infocus.pl?id=1292


9/20

As was mentioned in the first article, LDAP, or Lightweight Directory Access Protocol, is thetechnology on which AD is based. It is also the basis for Novell NDS. Some of you mayknow of a wonderfully talented hacking group at theNomad Mobile Research Center. Thisgroup released a number of things that relate to hacking Novell'sNetware. Not only did theyproduce a number of FAQs and how-tos concerning faults in the Netware OS, they also

released a well known tool called Pandora, which simplifies and automates the ability toattack a Netware-based host/network.

Some of the most dangerous (in my opinion) components of their research dealt not so muchwith Netware, but with LDAP. For instance, one of the problems with Netware was that a usercould glean all sorts of critical, sensitive information from an NDS tree (through an actioncalled "attaching" in Novell-ese. Some call it binding, but that might confuse those familiarwith older versions of Netware.) without even needing a valid login and password. Thisvulnerability was not based so much on Novell and NDS as it was LDAP.

So, do you think Microsoft implemented solutions for these kinds of problems? In short, the

answer is 'no.' It's not so much Microsoft's fault either; rather it is the fault of LDAP. It issimply not possible to write a directory service that is fully (or mostly, or partly, depending onwho you ask) standards-compliant, compatible and capable of being integrated with otherLDAP directory services (like NDS and some other UNIX-based releases) without inheritingthese problems. I have been led to believe that many of the vulnerabilities discovered byNMRC are "almost portable" to AD. These problems stem from the very beginnings ofLDAP, so that is where we'll start.

LDAP v2 is where our problems begin. (We won't cover LDAP v1, largely because I've hadlittle experience with it and it's not really involved with AD.) To begin with, we need to coverthe process of how one connects to an LDAP-based directory service (this all applies to AD).The connection goes as follows (I've taken the liberty of calling the LDAP database a "tree")in the diagram:
http://www.nmrc.org/http://www.nmrc.org/http://www.nmrc.org/http://nw6launch.novell.com/nw6launch/index.jsphttp://nw6launch.novell.com/nw6launch/index.jsphttp://nw6launch.novell.com/nw6launch/index.jsphttp://nw6launch.novell.com/nw6launch/index.jsphttp://www.nmrc.org/


10/20

The important lesson to learn here is just how much one can gather from an LDAP treewithout authenticating. In some cases, if permissions are set strictly for user objects butnothing is considered for the "anonymous attach-er", the "attach-er" will be able to get acursory vision of more of the tree than an authenticated user object. Likewise, making ananonymous connection and/or attachment to an AD tree (as was mentioned in the e-mailsnippet) may earn a curious/malicious party quite a bit of sensitive information. Also, as theflowchart illustrates, in LDAP v2, unless some secure authentication module has been addedto the LDAP server, authentications are done in clear text. Out of the box, Active Directorydoes a decent job of not allowing clear text authentications. However, if users are integratingAD with some other LDAP server, they should beware. They may unthinkingly allow cleartext authentication to occur simply to be compatible. Readers should take care when

considering just how much LDAP v2 functionality they will allow in their network.

However, as was mentioned previously, as far as out-of-the-box requirements for encryptionis concerned, AD does a good job handling the authentication. That's not to say that therearen't problems with the authentication systems (see SecurityFocus'sWindows 2000 LDAPSSL Password Modification Vulnerabilityreport as one big example), but AD is capable ofdoing a better job because it is also built to support LDAP v3. LDAP v3 is stronger than v2 interms of authentication and security. The possibility for making anonymous attachments togather information still exists; however, LDAP v3 integrates SASL into the picture. WithSASL, any authentication/encryption system can be implemented. In the case of ActiveDirectory, Microsoft chose to go with Kerberos v5? sort of.

Active Directory and Kerberos
http://www.securityfocus.com/vdb/bottom.html?vid=2929http://www.securityfocus.com/vdb/bottom.html?vid=2929http://www.securityfocus.com/vdb/bottom.html?vid=2929http://www.securityfocus.com/vdb/bottom.html?vid=2929http://www.securityfocus.com/vdb/bottom.html?vid=2929http://www.securityfocus.com/vdb/bottom.html?vid=2929


11/20

Microsoft's version of Kerberos is based on the MIT standard for Kerberos v5 but Microsofthas taken the protocol one step further, in a Microsoft direction, so to speak. That's not to saythat this is necessarily a bad thing. What it does mean is that a tried and true system developedby theIETFhas been tweaked it a little; as a result, it is now not a tried and true system,which means that there could be security design issues that could affect users directly. That

could mean some compatibility issues with other authentication systems in network that usesKerberos v5.

Microsoft has written theStep-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperabilityinorder to facilitate the interoperation of Kerberos with other systems (like some UNIX systemsusing kinit). Bear in mind, however, that such compatibility deviates both from the Windows2000/AD norm and from the UNIX norm. Why would this be a problem? Because withininteroperability, the two authentication systems are now no longer being implemented as theywere originally intended. Some readers may be thinking that this particular approach to thetopic represents an attempt to do spread fear, uncertainty and doubt. However, my ownpreliminary research and my views on computing security history lead me to feel some

uncertainty and doubt about the degree of security that interoperability can offer.

The following analogy may serve to illustrate this point. Anyone who is bilingual ormultilingual will tell you that there are occasions in which words, ideas, and phrases don'ttranslate exactly between two languages. In a case like this, one is forced to make someassumptions and some changes to the original word, idea, or phrase in order to properlyprocess it in another language. In other words, some leeway, extra room to operate, andflexibility is required. Leeway, extra room to operate, and flexibility may be important inlanguage, but they are not good when designing a secure system. In fact, they detract frommaking a system act/behave in an exact manner.

A system can generally be considered secure when it acts the same way, all the time,regardless of circumstances and conditions, and is incapable of acting any other way. This isdesirable because generally when an attacker breaks into a system, they are able to do so bygetting it to act differently than it should. Accordingly, getting an authentication system to actabnormally can result in such things as false authentications, bypassed authentications, andmore. How will Microsoft's Kerberos stand up to the test? Time (and more research) will tell.

LDAP and SASL

Getting back to the topic of LDAP v3, we come across a security technology introduced with

LDAP v3 called SASL, which stands for Simple Authentication and Security Layer. In thecase of AD authentication, SASL works with another technology: SPNEGO, or SecurityProtocol NEGOtiation. SASL and SPNEGO determine exactly what protocol or protocols canbe used to authenticate to the directory (in an ideal situation, where all LDAP v2 functionalityis as removed as possible.)

Currently, SPNEGO only seems to choose between two protocols, NTLM and Kerberos.(Some more experienced readers may be asking why I'm not mentioning the componentcalled GSS-API. I'm choosing to ignore it in this case for simplicity's sake). Users who opt toauthenticate to the directory with some other protocol will get an error message stating that nocommon authentication mechanisms are available.
http://www.ietf.org/http://www.ietf.org/http://www.ietf.org/http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asphttp://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asphttp://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asphttp://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asphttp://www.ietf.org/


12/20

One additional note about NTLM in the AD environment: using NTLM may effectivelynullify most of the benefits of using Kerberos. If an attacker can force NTLM negotiation innetworks and then crack the password hashes, it doesn't matter how effective Kerberos is inpreventing the option of sniffing for passwords, because an attacker has a way around it. (I'mcurrently in the process of researching and developing a utility that will effectively allow a

third-party attacker to force two systems to authenticate via NTLM, even when Kerberos isavailable for usage between them. This is still very much in the research phase, so please don'te-mail me to ask for it. I hope to publish an article on the topic sometime in the reasonablynear future.) As long as NTLM is in existence on a network, Kerberos should not be trusted toprotect passwords, because it cannot do so unless it's the only protocol available. Having abad password on a network with NTLM available is like forfeiting the benefit of Kerberosaltogether.

Bringing It All Together: SASL, Kerberos, LDAP v2 and LDAP v3 and AD Security

Having mentioned all of these technologies, let's answer the question of what SASL,

Kerberos, LDAP v2 and LDAP v3 all have to do with AD security.

AD is merely the directory that holds all the information. The technologies mentioned aboveare what protect it and make it function. A security weakness in any of these key technologiesrepresents a huge problem with the integrity of AD security. We've only just touched thesurface here by bringing up potential structural issues and there may be more structural issuesat hand, resulting in all kinds of vulnerabilities.

This article has addressed numerous, seemingly unrelated technologies; however, I would askreaders to keep in mind that this series of articles are intended to be as much an introductionto the topic of AD security as possible. My desire in writing them has been to get peopletalking, thinking, and researching things about AD security. Each of the technologiesaddressed in this installment deserves individual scrutiny well beyond the scope that isavailable in this series of articles. That said, the key message of this article is that readersshould understand as much as possible about the components Active Directory beforeimplementing it; otherwise, how secure can users, and their networks, really be?

In the Next Installment

That concludes this discussion of LDAP, SASL, Kerberos and AD security. Although this hasby no means been a comprehensive look at the topic, I hope that it will give readers the basis

to be aware of some important security issues. In the next article, "Keys to the Kingdom, theConfiguration Naming Context: Some Caveats and Some Issues," will consider a verysensitive portion of the directory and some devious techniques for modifying it. We'llconsider modifying it in a relatively quiet, transparent fashion. We'll also consider modifyingit in a noisy, site-crashing manner.

This is the fourth in a five-part series on auditing Active Directory security. Thefirst articleinthe series offered a brief introductory overview of Active Directory. Thesecond installmentwe examined some of the security implications of the ADs default settings. Thethird articlewe looked at LDAP, SASL and Kerberos in the context of AD security. This installment willlook at some potential security concerns related to the Configuration Naming Context in AD.

Content Naming Context
http://www.securityfocus.com/infocus/1292http://www.securityfocus.com/infocus/1292http://www.securityfocus.com/infocus/1292http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1292


13/20

On to the topic at hand! I'd like to note that this particular article has been the longest indevelopment in the series so far; the reason being that playing with the Configuration NamingContext (CNC) tends to crash the directory service, sometimes in very hard-to-recover ways,such as rebuilding the server. Try it yourself, you'll find that, until you become very educatedon the topic of programming AD, the bulk of the changes you make will blow up your Active

Directory and, most likely, the server(s) housing the directory.

The title of this article (specifically the Keys to the Kingdom part) may seem a bit verbose butwith good reason. The reason this article considers the CNC to be the proverbial keys to thekingdom is that many critical objects are stored in the CNC. All sorts of replicationinformation is stored in the CNC, a factor that we shall be covering in the next article in thisseries. The AD schema and DSA behavior, privileges and such are all variables stored in theCNC. Query policies are stored in the CNC, as is information relating to DNS and thedirectory is also stored in the CNC. Basically, if AD had a brain and a set of operatingprocedures, it would be called the CNC.

Key Components of CNC

Well start with a couple of key components orattributes of Configuration Naming Context.While most of the components in the CNC could be considered as important, I am discussingcertain components as particularly important because they are crucial to an attack strategy onAD that I developed for this article. I have come across a number of ways that one mightattack AD but I consider this particular attack strategy to be the most devious that I know of.Because of the way I have layered the attack, it would be extremely difficult to trace unlessAD administrators keep extensive logs backed up on AD access activity or happen across thetrigger for the attack fairly soon after the trigger has been planted.

So what are the key components of the CNC that I have referred to? Some are simplyattributes of sub-contexts of the CNC, like some replication attributes (replUpToDateVector,repsFrom, repsTo,), which govern how components of the CNC replicate from server toserver and from database to database within the AD network. Others are sub-contexts orelements of those sub-contexts like DisplaySpecifiers (used in the social engineering exampleexploit discussed later in this article,) Services, Sites, Partitions, and Extended-Rights, whichcarries important security information for the directory.

Some key components, such as replication, don't really become key components until thedirectory reaches large scale, as would be indicated by many domain controllers, locations,

and forests. A full treatise on the CNC and all of its components would occupy a small book,one that, to the best of my knowledge, has yet to be written by anyone. Hence, we won't enterany extended detail on any of these sections unless they involve the quiet and noisyattacks/modifications to the CNC. We'll start with the quiet attack:

Quiet Attacks on CNC

This particular attack also utilizes the Microsoft Management Console (MMC) as the ultimatepoint of execution. The attack is considered quiet because it doesn't directly damage or causeany sort of malfunction in the directory and is not incredibly noticeable. That's not to say thatthe MMC is necessarily the target of the attack (remember, this is all about the Directory,) it's

just the medium used to channel the attack. Consider the following screenshot:


14/20

As you can see, the subnet type listed below has been modified to say, "My Father's Name isMary 2", rather than what it should read, which is, "Subnet". On its own, this is probablyfairly innocuous, a simple little joke made to change the directory type listing. This changehas been made simply to illustrate that applications may access the directory to determinewhat and how to behave. However, this little change can get to be fairly serious if

implemented properly and creatively.

Suppose that rather than modifying the string with "My Father's Name is Mary 2," Subnetwere inserted with a "binary blob" (as they call it in AD-ese,) in front of it. Suppose also thatthis binary blob caused the machine that was running the management console to execute apiece of malicious code in the background, all without the knowledge of the administratorwho launched the program and referenced the menu. Now, I'm not saying that modifying thisexact section of the directory in this manner would create the capability of yielding suchresults, but modifying it or other sections could. (Incidentally, the RDN for this particularchange is CN=subnet Display,CN=409, CN=DisplaySpecifiers in the CNC, under theattribute classDisplayName.)

If you're still unclear as to what, why, or how this works, look at it this way: you may knowthat Microsoft's MMC is very expandable programmatically. What you may not know is justhow expandable it is. You really don't need a buffer overflow to dump in the kind of code-bomb I am (vaguely) talking about. Consider the ability to dump this kind of code in as afeature courtesy of Microsoft (like the programmatic/macro features of e-mail with MSOutlook.)

What makes this dangerous is that normally an MMC is entirely dependent on localinstallation and configuration. Lacking some fancy SMS rollouts and some tricky install scripttweaking (with malicious intent,) you'd be hard pressed to find a good way to Trojan an entireenterprise's MS administrative controls - until AD, which allows certain portions of an MMC,such as the AD sites and services or AD "User Manager", to be modified to an entireenterprise because portions of the MMC are loaded from the directory itself. The screenshotthat you see above isn't the result of modifying a local machine's MMC controls; it's the resultof modifying the directory, which is then read by the machine and executed locally. Now,there are certain small formatting bounds for different sections of the MMC: for instance,some sections of the MMC will say that they only interpret, and therefore execute, certain setsof characters or formatting schemes (i.e., ASCII strings versus hex values.) In at least onecase, you can actually write a "binary blob" in C and implant it "raw to the directory", and itwill work (meaning that, in this case, if you could program malware in C, you'd be fully

prepared to infect the directory.)


15/20

Therefore, if one presents data (say, in the form of a RAT) to the MMC in the proper format,the MMC will read and execute it, with nearly boundless possibilities. With the current super-powerful nature of the languages/programming features for MMC there is no need for a bufferoverflow or some such thing. However, with the current open nature of MMC in general andthe lack of documented security testing for it, I wouldn't be surprised if they also exist. I

haven't searched for buffer overflows because I didn't need to.

So, without providing the actual code-bomb, there you have it. In terms of the formatting andunderstanding of how MMC executes things that is necessary to pull it off, you can consider itsimilar in some respects to representing Web requests with a Unicode string. After all, howmany people thought that one might be able to manipulate a Microsoft Web server just bypresenting it with a differently formatted request? The same principle applies here. Theeffects of this could be similar to downloading hostile content from Web sites.

This is much different in that people know they need to be careful about the nature of sitesthat they visit, but no administrator is going to think twice before launching his MMC and

naively clickety-clicking his or her way into infection/exploitation. Nobody has infected anMMC yet, but now they can and, by so doing, may have an effective means of distribution.The impact could be equal to what the Remote Explorer virus did to MCI a few years ago.However, this requires much less skill to write because the writer doesn't really have to focuson getting the malware to network in the code once it is implanted in the directory - thedirectory networks the malware.

I mentioned in an earlier article in this series that the directory was like one giant livingregistry. We all know about viruses that base themselves in the registry to some extent, andthere is probably a way to fully implant a virus in the registry on a machine that doesn't useAD. There is definitely a way to fully implant a virus in AD, which means that there is a wayto get that virus to other machines on the AD network.

One thing to note in this example is that, because the administrator has launched thisparticular MMC snap-in, the code will be executed with high privilege, thereby allowing it todo just about anything (other than going out to get the administrator some coffee.)

Some other thoughts on this quiet binary blob payload and an attack strategy...

AD is distributed. Suppose one were to code this payload to modify other portions of thedirectory by self-replicating to them. Suppose that in addition to a self-replication feature, this

payload contained some kind of RAT or virus that would replicate itself to nodes on thedirectory/network (like workstations, or exchange servers) when they access the portions ofthe directory that have been implanted with the payload. Supposing all that were to beaccomplished, the distributed AD would become a means for quietly and effectivelydistributing attacks. Some would go so far as to consider an AD modified in such a way to beone very large Trojan. This Trojan would be particularly mean and nasty because removing itcould risk corrupting the directory and bringing down an entire network, rather than just oneworkstation.

Just imagine the additional bandwidth that would be used up when workstations receive thereplication. Also imagine the fact that the Trojan would continue to reinfect machines (or, at

least, attempt to) until the directory were replaced or cleaned. Your average systemadministrator isn't going to have the necessary skill to go in and modify the directory to clean


16/20

the Trojan without substantial risk of destroying the directory. (I get panicky just thinkingabout it!) Nimda and Code Red were death to corporate networks with unauthorized webservers installed inside the network, especially in regard to bandwidth utilization. The solutionin there was to remove all the unauthorized Web servers and harden those that wereauthorized. What's the solution here? Remove the rogue directory? I see a possible need for

AD virus scanners and reference-based integrity checkers in the future.

Now, as to modifying AD in a noisy, site-crashing manner: well, there are many easy ways todo that - just delete a major subsection of the directory. The deletion DisplaySpecifiers has anespecially nifty effect, although in my experience, this will only intermittently result inimmediate site crashing (I personally have had intermittent behavior with this.) DeletingDisplaySpecifiers makes it really difficult to administer an AD though, because most of theAD MMC administration software will no longer have any labeling to it! DeletingWellKnown Security Principals or Extended-Rights will usually bring a site to its knees aswell. Obviously, deleting the Schema or modifying a critical attribute name in the Schemawill also cause serious damage.

Caveats and Issues

What lessons are to be learned from this? The caveats and issues mentioned in the title arequite simple. The primary caveat being that CMC is not necessarily secure and that systemsadministrators need to be aware of these potential vulnerabilities. Do you think that Microsoftpaid much mind to the security of the actual directory in the creation of AD? It doesn't appearso. Perhaps it is not their main concern, but it is my opinion that particular sections of thedirectory mentioned in this article should have some additional levels of protection to them,both in the way they are accessed and in the way they function. Until that protection isimplemented, I would not before I'd want to subject my network to the level of broad reachingpower given by the directory. What are the issues? The issues are that, to the best of myknowledge (and I've done some pretty steady investigation on this point,) nobody in thesecurity community seems to have noticed, let alone developed a solution to this problem.

I'll concede that administrative access is required to make changes like this. However, by myexperience, gaining administrative access to most NT networks once a person has any sort ofaccess to those networks is not incredibly difficult. Just because AD is now attackable doesn'tmean the world ends, it just means that with AD, an attacker with the proper tools andknowledge would have an incredibly potent weapon in his hands.

Conclusion

Stay tuned for the next article, entitled:A Theoretical Attack on the Multi-Master ReplicationScheme in a Massively AD Enabled Network in the Enterprise (a.k.a. what the disgruntled

employee/ex-employee could do to really screw up an organization). We'll considerfundamental weaknesses in multi-master replication technology and the impact that has onAD and the security of an AD network.

This is the fifth and final installment in a five-part series on auditing Active Directorysecurity. Thefirstarticle in the series offered a brief introductory overview of ActiveDirectory. In thesecondinstallment we examined some of the security implications of the

ADs default settings. Thethirdarticle looked at LDAP, SASL and Kerberos in the context ofAD security. Thefourthpart looked at some potential security concerns related to the
http://www.securityfocus.com/infocus/1292http://www.securityfocus.com/infocus/1292http://www.securityfocus.com/infocus/1292http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1509http://www.securityfocus.com/infocus/1509http://www.securityfocus.com/infocus/1509http://www.securityfocus.com/infocus/1509http://www.securityfocus.com/infocus/1470http://www.securityfocus.com/infocus/1293http://www.securityfocus.com/infocus/1292


17/20

Configuration Naming Context in AD. This article will examine some issues surrounding themulti-master replication scheme.

The basis for this article begins with the following question:

if two separate nodes on a directory-enabled network commit actions on the same object inthe directory at (approximately) the same time, which nodes actions will be considered final,and how will the details be replicated accurately?

The purpose of this question is to lay the groundwork for a discussion of the theoretical attackmentioned in the title of this article. Hence, we will first establish a hypothetical scenario thatillustrates how and why such an attack may be possible in a generalized multi-masterdirectory service, after which we will jump into a discussion of how Active Directory handlesthe conditions mentioned in the hypothetical scenario. Upon completion of that discussion, wewill discuss how to circumvent Active Directory's controls and make the hypotheticalscenario (and worse) happen anyway.

A Hypothetical Situation

Suppose my fellow system administrator, Bob, and I have both been given a long list ofchanges that we need to make to our organizations Active Directory. Suppose that neither

Bob nor I are aware that the other has a list of changes to make. Bob and I have separatelyplanned to make these changes at the same interval in time during the work-day. Finally,suppose that Bobs list and my list differ slightly on most changes to be made (say, Bob has

version 1.0 of the list and I have version 1.1).

When Bob and I make our respective changes, what impacts could they have on the directory?Assuming that the directory has no controls in place to deal with activity of this sort, anynumber of things could happen. The directory could end up with two instances of the same

object, a corrupted object, and or an object with some of Bobs changes and some of mychanges in effect. Any of these could result in user objects having an amalgamation of rightsand/or multiple passwords (among other things). They could also result in critical portions ofthe directory (whether critical to the system or to the user base, it doesnt matter) getting

changed and replicated in such a way to cause serious problems.

Replication could be an especially big problem if the changes were made on separate serversposessed of the same replica (as is commonly the case in a multi-master scheme). Ever play

the rumor game in which one person whispers something in the ear of another person, whothen whispers it to the next person down the line of people, so that the end message soundsnothing like the original? This is much like what could happen in replication. However, thereplication cycle would probably be endless (as opposed to the rumor game) as there wouldnever be a finalized copy.

This could create a number of problems on a directory-enabled network. For instance, thedirectory could crash/shutdown, effectively causing network outages (especially if DNS is

integrated into the directory). Furthermore, the various master-nodes (replica-carryingservers) could get into contention over which has the most recent object, forcing constantreplication, chewing up CPU clock-cycles and bandwidth.


18/20

While one might say that the biggest problem underlying this scenario is simply the fact thatBob and I are not communicating adequately to properly coordinate our efforts. In this case, Iam giving it serious consideration because it represents a significantly common situation and,therefore, should be addressed.

Managing Coincident Changes with Active Directory

Active Directory takes a very simple approach to tackling this problem. For the purpose ofdescribing Active Directorys solution to this problem, well consider that the Active

Directory network we are talking about here constitutes onesite. From here, well note whatActive Directory does at each step of the process of Bob and I implementing our respectivechanges.

When I implement my changes at Server A and Bob makes his changes at Server B, eachobject that we move, add, and/or modify carries a number called an Updated SequenceNumber (USN), which is incremented on each server. The same object, on two different

servers, carries a unique USN. In addition to that, each servers replica of the directory carriesa unique USN that increases in increments every time a change is made to that replicascontents. The servers keep track of their partners replicas USN and the USN(s) of each

object/attribute on that partner in order to keep track of change.

The general effect that this has is to improve the stability of the overall directory state inregards to data integrity in the replica. It also means that consistency between replicas ismaintained more loosely and that automatic (unforced) synchronization is generally much lesstimely than one might expect. The exception to this consistency rule is if the object in thedirectory is labeled with an attribute called isCriticalSystemObject, in which case,synchronization is forced.

So when Bob and I make our changes to the same data on separate servers at roughly thesame time on the same objects and/or attributes, the server with the highest change in USN foreach object is treated as the most recent copy for each object and attribute. In other words, theUSNs are compared before replication and the highest USN wins.

AD replication geeks can poke holes in this example for incompleteness, but, as statedpreviously, it serves as a basic example for arguing the theoretical attack. For those whowould like a more comprehensive explanation, although by no means complete, check out thefollowing URLs:

http://support.microsoft.com/servicedesks/webcasts/so_projects/so12/soblurb12.asp http://support.microsoft.com/servicedesks/webcasts/so_projects/so13/soblurb13.asp http://support.microsoft.com/servicedesks/webcasts/so_projects/so14/soblurb14.asp http://support.microsoft.com/servicedesks/webcasts/so_projects/so15/soblurb15.asp

The Theory Behind the Potential Attack

But how does Active Directory behave when the conditions created by Bob and I becomeexceptional (i.e., are widely expanded and implemented at much more drastic speeds thanusual)? This is where the theory comes into play, and the simplest way to apply the theory is

to start changing USNs at random, to random objects, and at rapid speeds. In other words, toaccelerate the application of the theory, start changing USNs, objects, and attributes at
http://support.microsoft.com/servicedesks/webcasts/so_projects/so12/soblurb12.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so12/soblurb12.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so13/soblurb13.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so13/soblurb13.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so14/soblurb14.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so14/soblurb14.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so15/soblurb15.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so15/soblurb15.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so15/soblurb15.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so14/soblurb14.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so13/soblurb13.asphttp://support.microsoft.com/servicedesks/webcasts/so_projects/so12/soblurb12.asp


19/20

random, while always adding the option TRUE to the attribute isCriticalSystemObject, to

all objects in the directory.

Now, before we start talking about the effects of this on Active Directorys behavior, and theglobal effect that such behavior will have, lets talk about what is required to commit such

behavior. First off, rights that are higher than that of Administrator are required. In order tochange USNs at will, Local System authority is required. Otherwise, in order to put the theoryin effect, one would have to come up with an engine that would still require at leastadministrative rights to operate, and would randomly and rapidly request random changes tothe objects in the directory, thus effecting changes to the USNs of these objects. Withadministrator rights, one can still utilize the accelerating effect of isCriticalSystemObject:

TRUE. So, having completed all the aforementioned items, stop and take a breath for amoment

Now, toss in a replication cycle or two (if the system even makes it past one cycle)

By now, I would expect that you realize what this could do to a large, massively AD-enabledorganizations network: highly distributed, effective, denial of service to both the networkitself and the respective Multi-Master nodes (and all components of desktop operation thatrequire the directory in order to function). By my best estimates, such a denial of servicewould also be extremely difficult to stop, and even more difficult to repair the damages.

Prevention of the Potential Attack

Readers who are inclined to consider the effects of this will quickly see that there are anumber of ways to spin and or enhance this theorys intent. That much is easy, but how doesone attempt to prevent such a thing from happening?

I assume that in order to have the time, permissions, and malice to do this, one would have tobe a system administrator employee/ex-employee of an organization that owns a sizeable ADenabled network. So the first step in preventing this could simply be considered good, secure,careful internal security administration. However, if all people and all organizations werecompletely effective at such a thing, distributed denial of service would not be the topic ofdiscussion that it is today.

The use of ingress and egress filters to monitor rates of change and change requests in thedirectory might also be effective at preventing bandwidth blackouts, but I dont believe that

such a system (the way I imagine most think of ingress/egress monitors) would prevent amore slow and generalized data corruption that would occur.

Having reading this, some will ask: Why waste your time with such a theory when you could

just as effectively cause a mass denial of service through other non-electronically-basedmeans (such as bombs, wire cutters, fires, etc)? The explanation is simple and threefold. First

of all, I would not discount the possibility of something like this happening, as there is clearrecord of similar things that have happened in the past (like the chaos that theRemoteExplorer virus/worm wrought, or the script that some disgruntled sysadmin wrote atCompany XYZ that went through and randomly deleted files over time). Secondly,discussions of hypothetical situations like this raise awareness of issues that need to be

addressed, like the general state of security with Active Directory, small parts of which havealready been brought to light both within and without this series of articles. Thirdly, I'm


20/20

speculating here, but I'm pretty sure I'm not the only person who has considered suchvulnerabilities.

In Conclusion

To close this series, I hope that this series of articles have raised your level of ActiveDirectory enlightenment and awareness. I sincerely enjoyed the time that I have hadresearching and writing it all. Despite the criticisms leveled here and elsewhere against AD,and despite its inherent problems, I still hold the opinion that it is a fantastic technologybecause of its relative ease of use, scalability, and integration. However, as has beenmentioned before by others, these things all come with a price greater than the one you payout of your wallet.

Documents

AD Audit by Symantec