|Chapter 1: A Non-Introduction to Active Directory|
|Chapter 2: Monitoring Active Directory|
|Chapter 3: Active Directory Troubleshooting: Tools and Practices|
|Chapter 4: Active Directory Security|
|Chapter 5: Active Directory Auditing|
|Chapter 6: Active Directory Best Practices|
|Chapter 7: Active Directory Lightweight Directory Services|
|Chapter 8: Assorted Tips and Tricks for Active Directory Troubleshooting|
|Complete Book (ZIP file)|
Loaded with valuable information about Active Directory (AD), The Definitive Guide to Active Directory Troubleshooting, Auditing and Best Practices shares best practices, tips and tricks, step-by-step testing procedures, and diagnostic approaches that will help you to ensure the reliability and performance of your directory. You'll also learn the latest techniques and practices for auditing Active Directory, learn best practices for managing and operating AD, and much more.
The world has been using Active Directory (AD) for more than a decade now, so there's probably little point in doing a traditional introduction for this book. However, there's still a bit of context that we should cover before we get started, and we should definitely think about AD's history as it applies to our topics of troubleshooting, auditing, and best practices.
The point of this chapter is to identify key elements of AD that you need to completely inventory in your environment before proceeding in this book. Much of the material in the following chapters will refer to specific infrastructure elements, and will make recommendations based on specifics in common AD environments and scenarios. To make the most of those recommendations, you'll need to know the specifics of your own environment so that you know exactly which recommendations apply to you-and a complete, up-to-date inventory is the best way to gain that familiarity. To conclude this chapter, I'll briefly outline what's coming up in the chapters ahead.
The fact is that you can't really do anything with Active Directory (AD) unless you have some way of figuring out what's going on under the hood. That's what this chapter will be all about: how to monitor AD. I have to make a distinction between monitoring and auditing: Monitoring, which we'll cover here, is primarily done to keep an eye on functionality and performance, and to solve functional and performance problems when they arise. Auditing is an activity designed to keep an eye on what people are doing with the directory—exercising permissions, changing the configuration, and so forth. We have chapters on auditing lined up for later in this book.
In this chapter, I'll introduce you to a structured directory troubleshooting approach developed by Directory Services MVP Award recipient Sean Deuby. We'll use Sean's approach as a guide toward tracking down problematic AD subsystems and solving problems. At the same time, I'll explain core troubleshooting techniques that will help make you a more efficient and effective troubleshooter.
In the security world, AAA is usually the term used to describe the broad functionality of security: authentication, authorization, and auditing. For a Windows‐centric network, Active Directory (AD) serves one of those roles: authentication. Internally, AD also has authorization and auditing functionality, which are used to secure and monitor objects listed within the directory itself. In this chapter, we’ll talk about all of these functions, how AD implements them, and some of the pros and cons of AD’s security model. We’ll also look at reasons your own security design might be due for a review, and potentially a remodel.
This chapter will also discuss security capabilities usually acquired from third parties. I know, it would be nice to think that AD is completely self‐contained and capable of doing everything we need from a security perspective. In a modern business world, however, that’s rarely true, as we shall see.
The previous chapter was about Active Directory's (AD's) declarative security—that is, how you tell the directory who has permission to do what. We also had a look at how AD's security is designed and built, and how AD as an authentication mechanism interfaces with Windows' native authorization mechanisms. Those were the first two of the "three As," and the third one—auditing or accounting—is the focus of this chapter.
Goals of Native Auditing
Auditing has a fairly simply goal: Keep track of everything everyone is doing. Within the context of AD, that means keeping track of all uses of privilege, such as changing group memberships or unlocking user accounts. It also means keeping track of account activity, such as successful logons and failed logons. Extending that scope to Windows, auditing includes keeping track of file and folder access as well as changes to file permissions.
Your goals for auditing might differ somewhat from the goals of the operating system's (OS's) auditing architecture. Keep in mind that the auditing system used in Windows— including AD, which essentially just copied the architecture of the file system—dates back to the early 1990s when Windows NT was being designed and written. At that time, Microsoft couldn't have predicted organizations with thousands of file servers, dozens or hundreds of domain controllers, and thousands of other servers running Exchange, SQL Server, SharePoint, and other business platforms. The fact is that Windows' native auditing architecture doesn't always scale well to especially large environments, or even to some midsize ones—a fact we'll explore later in this chapter. So although you might want to audit every single event in your environment, actually doing so may create performance challenges, management challenges, and even logistical challenges. For right now, let's just assume your goal is indeed to audit everything that happens in your environment, and see where the architecture takes us.
This chapter is a kind of "miscellaneous best practices" list. The trick with AD and best practices is that there's never any one right answer for every organization. You have to temper everything with what's right for your organization. So really, this chapter is intended to simply give you things to think about within your environment, and ideas that stem from what's worked well for other folks in situations that might be similar to your own.
Should You Rethink Your Forest and Domain Design?
First of all, step back and take a look at your domain and forest design. How perfect is it? AD design unfortunately has two conflicting goals: One is to support your Group Policy deployment, and the other is to support delegation of permissions. For the first goal, you might organize AD to really facilitate using a minimal number of effective Group Policy Objects (GPOs), especially if you need differing GPO settings for various company departments and divisions. The second goal focuses on who will manage AD objects: If you plan to delegate permissions to reset passwords, for example, then organizing your directory to group those delegated user objects will make the actual delegation easier to set up and maintain.
Keep in mind that Group Policy is the one thing you pretty much can't separate from the directory. From a security and delegation perspective, third‐party tools can abstract your directory design. For example, many third‐party identity and access management (IAM) tools enable you to delegate permission over objects that are distributed throughout the directory. You essentially use the tool to manage the delegation, and it deals with whatever ugly, under-the-hood permissions it needs to. In some cases, these tools don't actually modify the underlying directory permissions at all. Instead, they provide "in-tool" delegation, meaning they act as a kind of proxy manager, providing different user interfaces for delegated users to accomplish tasks like resetting passwords or modifying user accounts. That kind of abstraction can let your underlying directory structure conform to other needs—like those of you Group Policy deployment.
In the Windows Server 2003 timeframe, Microsoft introduced Active Directory Application Mode, charmingly referred to as ADAM. These days, ADAM has grown up and changed his name to ADLDS (or AD LDS, if you prefer): Active Directory Lightweight Directory Services, which is distinct from the AD directory service that we're usually referring to when we just say "Active Directory." In this short chapter, we'll explore what AD LDS is all about, when you should (and shouldn't) use it, and how to perform basic troubleshooting and auditing with it.
We're at the end of this guide, and I find myself left with several things I wish I'd mentioned earlier-except that these things don't fit neatly into any of the topics we've already discussed. So in this chapter, I'll present these seemingly-random, yet completely-helpful, tips for troubleshooting various aspects of Active Directory (AD).
By sponsoring a book with Realtime Publishers, you will connect your technology company with thousands of IT professionals who need information on the technology topic of your choice. Realtime Publishers works with only the best authors in the IT field to produce expert-level publications that appeal to and educate the IT professional audience.
Visit sponsorships.realtimepublishers.com to learn more about our wide array of sponsorship and content marketing opportunities.