- Shopping Bag ( 0 items )
Advanced Coverage for Experienced Network Administrators
Active Directory Best Practices 24seven is written specifically to build on the practical and conceptual knowledge you've already earned. Taking a "just the facts, ma'am" approach this book provides targeted instruction and insider tips to help you quickly implement the best practices established by successful network administrators across a wide range of industries. This is also an excellent way to make a pain-free ...
Advanced Coverage for Experienced Network Administrators
Active Directory Best Practices 24seven is written specifically to build on the practical and conceptual knowledge you've already earned. Taking a "just the facts, ma'am" approach this book provides targeted instruction and insider tips to help you quickly implement the best practices established by successful network administrators across a wide range of industries. This is also an excellent way to make a pain-free transition to the latest release of Active Directory. Coverage includes:
How do you optimally design a database that replicates only parts of itself to as many as thousands of domain controllers at differing intervals? Therein lies the need for this book. Active Directory may very well become the largest database implementation within your organization. If you talk to very many database administrators, you will see them cringe when you mention that you would like to replicate a database to multiple servers. But that is exactly what you are going to do with Active Directory and your domain controllers.
Throughout the first section of this book, I am going to discuss design criteria that you should consider when designing your Active Directory infrastructure. The chapters in Part I are organized simply. To do an Active Directory design, go through the chapters in order. By doing so, you will end up with a good understanding of the building blocks for a design that allows for efficient administration and control of the entire Active Directory environment.
Active Directory is a technology that is unlike most directory services in that it is an integral part of the operating system (OS). The many other directory services out there "sit on top" of the OS. Netware Directory Services (NDS), for example, can be easily upgraded independent of an OS upgrade. Not so for Active Directory. To update the directory service on the Microsoft platform, you currently need to upgrade to the latest Server OS or service pack. Each service pack brings a host of bug and security fixes for Active Directory, as well additional functionality; therefore, you should apply the latest service pack on all of your domain controllers within a month of its release-although that is easier said than done.
Take note that Active Directory enhancements, features, and functionality are greatly upgraded by Windows Server 2003. The move from Windows 2000 to 2003 requires very little planning. The two databases are built on the same underlying technologies, but Microsoft learned a lot after the initial rollout with Active Directory under Windows 2000. Consider Active Directory in Windows Server 2003 as version 2.0 to the 1.0 Active Directory version in Windows 2000-this is an unofficial versioning that's included just for illustrative purposes. New administrative tools have been added and additional functionality has been included. However, for most of the added functionality, you will need to retire all of your Windows 2000 domain controllers. I'll discuss more on that later in this chapter as we review the functional levels for domains and forests.
You should consider moving to Windows Server 2003 for a myriad of reasons, not the least of which is the support timeline expiration of Windows 2000. Mainstream product support expires five years after a product release. Many in the IT industry will take the conspiracy theorist's stance and accuse Microsoft of retiring products in order to keep companies on the purchasing side of the table. However, in our industry, you must admit that the technologies that develop over the course of five years tend to make operating systems and applications obsolete. For those of you who have left Windows NT 4 for the greener pastures of Windows 2000 and Active Directory, could you even imagine trying to perform some of the administrative tasks on Windows NT 4 that you can perform with the newer technologies?
Tip For more information on the lifecycle of operating systems and applications, peruse the article on Microsoft's website support.microsoft.com/default.aspx?pr=lifecycle
In the following sections, we are going to look at the criteria you should consider when developing your Active Directory design. Most of the information included comes from working with Active Directory over the past few years and the methodology that has proven to work the best. While some of the information may seem like it is common sense to you, there are times when common sense seems to take a back seat to the desire to implement technology.
Active Directory Forest Design Criteria
Active Directory design is both technically and operationally driven. It requires compromise among diverse groups that may be used to doing tasks their own way-DNS admins can use Unix for DNS, NetWare admins have a different architecture of directory services that they want to implement, ERP packages use their own directory service, proxy/firewall/internet access might use its own directory service, mail uses its own directory service.... You get the idea. How do you please everyone in your design? You probably won't. Start by developing the ideal design by yourself, if possible, and then let each group have its turn telling you what modifications they would like to see or, in a worst case scenario, why your design won't work. If you let each group try to design Active Directory, you'll never get done.
Get executive sponsorship in the design phase. I cannot stress this point enough. In other words, find an executive to approve the design phase of Active Directory with input from other groups (afterward). If you make an executive ally within the organization and they trust and like your plan, you will find that getting the design approved and moving on to the planning stages will be much easier. A college professor of project management once told me that executive sponsorship of projects is the number one indicator of whether a project will get done. He actually buys stock in companies that have good project management business processes. He says he does well with his stock picks.
Active Directory design is about putting structure around a chaos of unorganized objects. It's about administrative control and separating the service owners accountable for maintaining Active Directory and the services that support it from data owner administrators who are responsible for maintaining the objects within the directory. It is about architecting a solution that takes into account the limitations of the technology you are working with (Windows Server and Active Directory) and designing around the organizational day-to-day business. Your design needs to take into consideration speed/latency, name resolution, availability, security, disaster/recovery, hardware, etc.
Forest Design should be your first architectural element when designing Active Directory. A forest is the smallest instance of Active Directory. The forest is the topmost container in Active Directory. It is scalable beyond 5,000 domain controllers, 5,000 sites, and millions of users according to Microsoft's Branch Office Deployment Guide. Even the largest organizations should be able to contain all of the necessary objects within a single forest. You will find that other considerations will come into play when developing your design. Legislative, political, or organizational reasons may force you to move to a multiple forest design, but make sure there is a valid reason to do so. Later in this chapter, I will discuss the pros and cons of single and multiple forest implementations.
Although a forest is almost insanely easy to build, it is far, far more complex to design. Several options are available, and you need to know what roles forests and domains play within your organization. As you will see in the next section, the domain is no longer the security boundary, as it was under Windows NT 4. I will discuss the differences and the new technologies that make up the security boundary, replication boundary, administration boundary, schema, and Global Catalog.
A forest shares a single schema, which can be defined as the rules of what can go into a directory service. Active Directory is made up of objects, which are instances of an object class that have been defined by combining attributes to form what can be allowed within the directory. These rules also define where objects can be created and used within the directory service. Because all of the objects within the forest have to follow the same rules, there can be only one schema per forest.
Due to the important nature of the schema, you should not take its existence lightly. While you may not have to think about it on a daily basis, you will need to make sure that you do not allow anyone to have access to the schema. If changes are enacted within the schema, the results could be disastrous. Your organization may be one of the lucky ones that never have to modify their schema, but very few organizations are so lucky.
Many organizations will modify their default schema so that it will support directory-enabled applications. One such example, and probably the most popular, is the need to implement Exchange. Both Exchange 2000 Server and Exchange Server 2003 add many additional attributes and object classes to the schema. Prior to implementing an Active Directory-enabled application within your production environment, make sure you understand the ramifications of altering your schema. Test the application first in a test environment. Later, in the "Best Practices for Forest Design" section, I will discuss the need to change management. You should read this section if you want to control how changes are made to your infrastructure.
Note If you would like to see the schema extensions that are installed with Exchange 2000/2003, check out the information at msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/ e2k3_ldf_diff_ad_schema_intro.asp.
If you are extending the schema for an in-house application, consider contacting an Object Identifier (OID) issuing authority for the proper classification. Failure to do so could cause problems with other applications when they are installed within your environment. If an application needs to use an OID that is already in use, the application will fail the install. Windows Server 2003 will allow you to reclassify an attribute; however, Windows 2000 will not. As a best practice, you should contact one of the following organizations to verify that the OID is not in use:
* Internet Assigned Numbers Authority (IANA) hands out OIDs for free under the "Private Enterprises" branch.
* American National Standards Institute (ANSI) hands out OIDs under the "US Organizations" branch for USD 1,000.
* British Standards Institute (BSI) hands out OIDs under the "UK Organizations" branch.
* Visit iso.ch for information on your country's National Registration Authority.
While you are at it, register the OID so that no one else can use it for their commercial applications. Microsoft will validate all applications that you want to be certified for use within Active Directory. If you register your OID and someone else tries to use it, Microsoft will fail the application and the software vendor will have to change their application accordingly.
For information on registering OIDs for the ISO or if you are registering an OID under Microsoft's branch, see the following websites:
* msdn.microsoft.com/library/en-us/ad/ad/obtaining_a_root_oid_from_an_iso_ name_registration_authority.asp
* msdn.microsoft.com/library/en-us/ad/ad/obtaining_an_object_identifier_ from_microsoft.asp
The rules have changed since Windows NT 4. Under NT, the domain was the security boundary. If you were a member of the Domain Admins group, you had full control of your domain and were isolated from Domain Admins from other domains. Now with Active Directory, the forest is the security boundary in Active Directory (AD), not the domain. I get a kick out of clients who want to argue this point with me. Any Domain Admin on any domain controller throughout the forest can bring down the entire AD forest-either on purpose or by mistake. There are some simple ways to do this:
* Impersonate any user in the forest (in any domain).
* Read, change, or delete any Windows-secured resource or configuration setting on any machine (especially domain controllers) in the forest.
* Modify service accounts that run in the system context-that means operating system privileges.
* Run code in system context.
* Hide (bury) domain administrator-equivalent accounts for later use. I participated in an audit that found a hidden Admin account named GOD.
* Cause changes to replicate to other DCs. This is not a problem with database corruption; but it is for a denial-of-service (DoS) attack, which would be easy with a simple script that added users endlessly.
* Take ownership of files, folders, objects, attributes, and, thereby, breach privacy.
These are just a few of the many ways to bring down the Active Directory forest.
Note See Chapter 2, "Active Directory Domain Design," for more information on what Active Directory domains are used for and the design drivers behind them.
When you are creating your Active Directory design, you must account for who will become the forest owner. The forest owner is any account that has full control access to every domain within the forest. Any domain administrator in the root domain of the forest (the first domain created in the forest) is automatically made a member of the Enterprise Admins and Schema Admins Groups in Windows 2000. You should be thinking like the rest of us and take users/Admins out of this group immediately.
Active Directory forests provide for a complete replication boundary. Two Active Directory partitions, the configuration and schema partitions (or naming contexts), replicate on a forest-wide basis. Every domain controller within the forest will share identical data for these two partitions. Even if you have domain controllers from different forests within the same physical location, they will not share configuration and schema partition data; only those from the same forest will.
Another partition type, the application partition, can be configured to replicate to all domain controllers within the forest, but it is not mandatory that it do so. With an application partition, you have the ability to choose which domain controllers the partition will replicate to, thereby giving you a means of controlling some of the replication traffic within your organization. Later, in Chapter 3, "Domain Name System Design," we will look at how the application partition works and the benefits of using this new partition type.
You can see the naming contexts upon opening Active Directory Services Interface (ADSI) Edit, which is provided in the Support Tools on the Windows 2000 (W2K) or Windows 2003 (W2K3) CD under \SUPPORT\TOOLS. Figure 1.1 shows ADSI Edit with the naming contexts opened.
As you will see in the following chapter, the domain partition, or domain-naming context, is replicated only to other domain controllers within the same domain. Although this does improve performance by restricting the amount of replication throughout the organization, it does cause issues when users are trying to locate objects within other domains. To alleviate some of the problems associated with partitioning the forest into separate domains, a Global Catalog was introduced.
A Common Global Catalog
A forest also provides for a common Global Catalog (GC) within the forest. A Global Catalog is a domain controller that hosts objects from every domain-naming context within the forest. At first you might think that could be a lot of data for a domain controller to host. If the Global Catalog server were to hold all of the attributes from every domain within the forest, you would be correct. However, to keep network traffic at a minimum, only around 200 of the 1,700+ available attributes for each object are copied into the GC. The GC is like a giant cache of directory objects and attributes that keep you from needing to query beyond a single domain controller. For example, you could easily take a laptop from domain to domain, country to country inside the same forest and authenticate immediately because your user object (and every user object in the forest) is cached in the Global Catalog, which replicates forest-wide.
You can control which attributes populate the Global Catalog with the Schema Management MMC snap-in. Be warned though, in Windows 2000, when you make a change to what values get put into the GC, you cause a full GC replication throughout the forest. This is not a big deal in an office of 200 people, but it is very much a concern when you have a 9GB GC such as Microsoft. This does not happen in W2K3; instead, only the changed or added attribute is replicated throughout the forest.
Later, as we determine the placement of domain controllers, we will come back to the Global Catalog server. There will be specific locations where you should place Global Catalog servers so that users and applications have access to the GC. For instance, the GC is Exchange 2000/2003's Global Address List (GAL), so you need to provide constant access to the GC for all of your Exchange servers.
Excerpted from Active Directory Best Practices 24sevensmall TM/small by Brad Price Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Part 1: Design.
Chapter 1: Active Directory Forest Design.
Chapter 2: Active Directory Domain Design.
Chapter 3: Domain Name System Design.
Chapter 4: Sites, Flexible Single Master Operations, andGlobal Catalog Design.
Chapter 5: Organizational Unit Design.
Chapter 6: Exchange Design Considerations.
Chapter 7: Hardware Sizing and Placement.
Part 2: Deployment and Migration.
Chapter 8: Deployment.
Chapter 9: Domain Migration and Consolidation.
Chapter 10: NetWare Migration.
Part 3: Maintenance and Administration.
Chapter 11: Backup and Disaster Recovery.
Chapter 12: Optimizing the Active Directory Database.
Chapter 13: Troubleshooting Active DirectoryReplication.
Chapter 14: Maintaining DNS.
Chapter 15: Troubleshooting the File ReplicationService.
Chapter 16: Troubleshooting Logon Failures.
Chapter 17: Troubleshooting FSMO Roles.
Chapter 18: Group Policy.
Part 4: Security in Active Directory.
Chapter 19: Securing the Base Operating System.
Chapter 20: Securing DNS.
Chapter 21: Patch Management.
Chapter 22: Securing Active Directory.
Appendix: Scripting Resources.