Endpoint Protection

 View Only

An Audit of Active Directory Security, Part 1 

Aug 01, 2001 02:00 AM

by Aaron Sullivan

An Audit of Active Directory Security, Part One: An Overview of Active Directory and Security
by Aaron Sullivan
last updated Aug. 1, 2001

Introduction

Anyone familiar with security architecture of the Windows NT family of operating systems knows that one of the biggest threats to the structure is in the NetBIOS services. Such threats were 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 from nasty NetBIOS information-gathering tricks. Now there's a new Microsoft operating system on the block, with new directory services and authentication mechanisms, namely, Active Directory and a "Microsoftized" version of the Kerberos authentication system respectively.

Administrators with security concerns might be glad that NetBIOS and the old NT domain model 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 more insane L0pht Crackers, no more master browser disputes, and no more quick easy dumps of every critical server on a network by the service they provide. Administrators may think they are 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 are discovered, publicized, patched, and people are educated about them. Until then, users may be resting on a lot of yet undiscovered bugs. These bugs may prevent people from embracing Active Directory, despite all of its wonderful features.

This article is the first in a series that will discuss some potentially major security issues that may 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 the subject. This installment will offer a brief overview of Active Directory, as well as a very introductory look at some of the security issues surrounding it. The next few articles will discuss 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 AD Enabled Network in the Enterprise (a.k.a. what the disgruntled employee/ex-employee could do to really screw up an organization.)

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

LDAP

LDAP stands for Lightweight Directory Access Protocol. It is based upon X.500 Directory Access Protocol technology, but is much smaller and faster, with a lightened feature set that allows for it to be run and scaled on most hardware. LDAP is the basis for numerous commonly-used systems, and has quickly become THE technology for high speed, directory enabled 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 now exists as well and has many improvements over LDAP v2, some in the security realm, others in the schema and performance realm. Active Directory is compatible with both versions of LDAP, but only in certain distributions. While there is much discussion and dispute over exactly which distributions will and won't work with AD, this series won't comment on that issue 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 an overview of the entire technology (For a more in-depth overview, please see Support WebCast: Windows 2000: Directory Services, Part One.) For readers who are not currently using Active Directory, but who are considering migrating to it, the following section will offer 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 an authentication, a distinction that will become important to understand later) to the Active Directory "root" server for dgs.com using Microsoft's excellent ldp.exe tool. For reasons of brevity, 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 <0>: (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> highestCommittedUSN: 5824;  	2> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO;  	1> dnsHostName: dgs-active.dgs.com;  	1> ldapServiceName: dgs.com:dgs-active$@DGS.COM;  	1> 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 Name
DC = Domain Controller
CN = Canonical Name (or short/easy name)
NTDS = NT Directory Services
USN = Updated Sequence Number
SASL = Simple Authentication & Security Layer
GSSAPI = General Security Services API
GSS-SPNEGO = General Security Services - Service/Security Protocol Negotiator
DN = Distinguished Name
RDN = Relative Distinguished Name

Those of you that understand LDAP or have worked with Novell NDS will see that some of these names look familiar. For those of you that don't, or those of you that don't understand Active Directory in general. I recommend that you visit Microsoft's knowledge base or refer to the Support 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 one that 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 that the base information for the directory services agent is being retrieved. A receipt of a null signifies the completion of that run, and then we get a match of the domain name for the entry of DC=dgs,DC=com. Those of you who are familiar with Netware (which is also based on LDAP) might be seeing something that looks familiar. This information signifies that this server is the root server for the dgs.com domain. This concept ties directly to DNS, where there are also root name servers. In DNS terms, you might consider that this server is known as .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 about the actual server and tree. A standard response is included in the next entry, in which the aggregate information for the Schema Configuration for the DGS.COM tree is shown. The last 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 we are connecting to an AD server after a default installation, the only entry we should expect to see is NTDS.

Next, we move on to the general settings for this particular tree. The numbers that start each entry 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 contexts available are each of the entries separated by a semi-colon, namely: 'schema,configuration,dgs,com', 'configuration,dgs,com', and 'dgs,com'. If you're wondering why I separated the CNs by commas, it's because that's how one separates CNs in a syntactically correct manner. The next few entries should logically fit according to their labels before the DN is given.

What is a DN? A DN is simply a linking of all CNs and DCs relative to an entry. For example, one might call the c:\winnt\system32 directory the 'system32' directory and others would probably know what was being referred to. This naming convention would be referring to 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 the c:\winnt directory. If one wanted to be more specific, he or she might use the Distinguished Name, 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 and functionality it allows: it makes user administration, security policy administration, Exchange administration, 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 into account? 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 is going to needed in the security policy, both in technical and personnel sections. As well, incident response, the monitoring of both performance and security will also need to be taken into account in order to protect the information systems of the organization. In an AD network, in order to function, everybody has to connected in order to operate properly. This means that all users are exposed to potential propagation of viruses, trojans, and worms, as well as other security threats.

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

Conclusion

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

To read An Audit of Active Directory Security, Part Two: Understanding the Security Implications of Active Directory Default Settings, click here.

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.