This excerpt is from Chapter 2, Managing Active Directory Security, of the free e-book The Definitive Guide to Windows 2000 Security, written by Paul Cooke and published by Realtimepublishers.com. The entire e-book is available at http://www.bindview.com/ebook/.
Active Directory best practices
Win2K has been around for well over a year now, but there isn't a lot of consensus about how to best provide security in AD. This can be partly attributed to the fact that AD is actually quite complicated and not as well understood as it should be. I've even heard that Microsoft has problems trying to fully understand the complexities of AD. Another reason is the lack of AD implementations that are out there. Sure, Microsoft and a few other large organizations have implemented AD in their environments, but most organizations have taken a wait-and-see attitude toward AD; they've deployed Win2K to their desktops and server infrastructures while leaving their NT 4.0 domain infrastructure fully intact. Nevertheless, there are some basic best practices when it comes to AD that I don't think many people would argue with. This will be the focus of this section.
Native-mode domains
A homogeneous Win2K environment provides the optimum security capabilities for your enterprise. Unfortunately, many organizations find this a lot harder to achieve than you'd first anticipate. All too often, applications that are critical to the success of your business are running on a legacy version of NT, and management is afraid to touch them, or the applications just won't run on Win2K for some reason. Even worse, you may run into the stubborn vice president who just can't live without his trusty old Pentium 90 running Windows 95. So while your goal is to have all your computers running Win2K, it may not be feasible to achieve it immediately.
If you can't update your entire environment to Win2K, I suggest that you at least run your domain infrastructure as a homogeneous Win2K environment in native mode. Using the PDC emulator role, your domain infrastructure can still support down-level, non-AD-aware applications while experiencing the benefits of running in native mode.
Domain forests
When you first deploy AD in your enterprise, you're best off starting with a single forest design. This design is the simplest to create and maintain. It also benefits from the fact that all of your domain trusts will be automatic, two-way and transitive in nature. Your users will also benefit because they only have to search a single forest to find resources in the environment.
I'm a strong believer in a single-forest implementation, but situations do arise that necessitate creating more than a single forest. Typically, a multiple-forest deployment becomes necessary because of trust issues and the need to isolate a domain in one forest from other domains in other forests. These issues of trust tend to arise when different parts of an organization want control over the ability to add and delete domains from the environment, control over schema modifications and change procedures, and tighter control over who accesses their resources.
While I strongly urge a single production forest for all of your users, you might want to keep a separate forest for integration testing with your environment. This will allow you to design solutions for your enterprise without disturbing your core business.
>> Read the rest of this excerpt from Chapter 2, Managing Active Directory Security, of the free e-book The Definitive Guide to Windows 2000 Security.
For more information on this topic, visit these resources:
