p. 1

nd o s .net w m ag wi azine s guide to active directory sean daily darren mar-elia mark minasi john savill paula sharick douglas toombs

[close]

p. 2

windows .net magazine s guide to active directory by sean daily darren mar-elia mark minasi john savill paula sharick douglas toombs a division of penton media

[close]

p. 3

copyright 2002 windows .net magazine all rights reserved no part of this book may be reproduced in any form by an electronic or mechanical means including photocopying recording or information storage and retrieval without permission in writing from the publisher it is the reader s responsibility to ensure procedures and techniques used from this book are accurate and appropriate for the user s installation no warranty is implied or expressed.

[close]

p. 4

about the authors sean daily sdaily@winnetmag.com is a senior contributing editor for windows .net magazine and the ceo of realtimepublishers.com his most recent books are the definitive guide series realtimepublishers.com darren mar-elia dmarelia@winnetmag.com is a contributing editor for windows .net magazine and writes frequently about windows 2000 and windows nt topics his most recent book is the definitive guide to windows 2000 group policy realtimepublishers.com mark minasi http www.minasi.com/gethelp is a senior contributing editor for windows .net magazine an mcse and the author of mastering windows 2000 server 4th edition sybex he writes and speaks around the world about win2k and windows nt networking john savill john@savilltech.com is a qualified consultant in england and an mcse he is the author of the windows nt and windows 2000 answer book addison wesley and manages the windows 2000 faq web site http www.windows2000faq.com paula sharick paula@winnetmag.com is contributing editor and online columnist for windows .net magazine and a consultant specializing in windows 2000 and windows nt network design implementation and interoperability douglas toombs doug@netarchitect.com is a contributing editor for windows .net magazine the owner of netarchitect consulting an mcse a compaq ase and a novell cna he is a coauthor of mastering windows 2000 server sybex

[close]

p. 5

iv table of contents chapter 1 planning for active directory 1 the logical namespace 1 domains 1 domain trees 1 forests 1 the relationship between domains domain trees and forests 2 political and organizational factors 2 geographical factors 3 technical factors 3 domains and forests ­ one or many 3 keep the forest root empty 3 limit trips to other trusts 4 define a security policy for each domain 4 limit replication between dcs 4 sizing dcs 4 active directory sizer 5 sites and site links 6 naming contexts 7 connection objects 8 designing a site topology 9 gc servers 10 sysvol shares 10 dns zone records 10 group members 10 chapter 2 dns and active directory 11 choosing a dns server using caching-only servers centralizing cache with forwarders using split-brain dns using slave servers to protect intranet servers fitting into an existing dns structure 11 12 13 14 15 16 chapter 3 single-domain migration 17 putting pencil to paper upgrading your pdc bdcs and member servers finishing touches native mode reap the rewards 17 18 21 22 22 23

[close]

p. 6

v guide to active directory chapter 4 the active directory delegation of control wizard 25 the power of ous delegation and ad object security what can you delegate using the delegation wizard at wildwood checking the wizard s work testing and modifying delegations wizard weaknesses 25 26 27 27 30 33 34 chapter 5 monitoring and maintaining active directory 35 ad care and feeding help from the outside problem ­ resolution features alerting options ability to monitor ad changes product architecture support knowledge base sla awareness tools of the trade ad backup system-state components the ad backup bug ad defragmentation 35 37 37 37 38 38 38 38 38 39 40 42 43 chapter 6 active directory faqs 45 how how how how how how how how do do do do do do do do iiiiiiii audit ad let users search but not browse ad restore ad tune ad replication authorize a dhcp server in win2k move multiple users between ous create a distribution group with exchange 2000 remove ad if the demotion failed 45 46 46 47 48 48 48 50

[close]

p. 7

1 chapter 1 planning for active directory by darren mar-elia you can find no end of articles and white papers and even books emphasizing the importance of proper planning before implementing windows 2000 active directory ad in your infrastructure indeed if you think ad is just an incremental change from the way you do things in your existing windows nt 4.0 domain environment you re in for an unpleasant surprise a directory service such as ad significantly increases the manageability and complexity of your network infrastructure far from being just an extension of nt 4.0 domains ad provides features such as delegated administration and group policy-based desktop management and could even serve as a critical business platform for developing directory-enabled applications proper planning of this infrastructure is not only crucial it s required let s look at some of the technical considerations and challenges involved in planning an ad implementation from laying out your namespace to designing a replication topology the logical namespace planning an ad infrastructure starts with deciding how to lay out your namespace i.e how to organize your network resources within ad in nt 4.0 your namespace choices are simple and few domains support only two levels of hierarchy no delegation boundaries exist within a domain and netbios doesn t support hierarchical naming with the advent of ad a hierarchical directory service based on x.500 concepts and using dns for its name service your choices are much more complex the ad namespace has three main tiers domains domain trees and forests domains a domain is the security boundary in ad just as it is in nt 4.0 an ad domain shares a common security policy and the same security groups such as domain local and global groups a domain is also a replication boundary ad replicates domain a objects only to domain a domain controllers dcs domain trees win2k introduces a new concept the domain tree a domain tree is a hierarchy of domains that are part of a contiguous dns namespace for example the top-level domain mycompany.com might have two child domains east.mycompany.com and west.mycompany.com the three domains form an ad domain tree mycompany.com might also create the subsidiary yourcompany.com and build a separate domain tree with the dns namespace yourcompany.com forests forests are another new ad feature a forest is a collection of one or more domain trees that share a schema and a kerberos security boundary each forest can have only one schema which

[close]

p. 8

2 guide to active directory defines ad s objects and properties transitive kerberos trusts connect all domains within a forest a forest treats domains outside itself the same way nt 4.0 domains treat one another with respect to trusts so if you build two forests in your enterprise and want to share resources between them you must use old-style nt 4.0 nontransitive trust relationships to do so in addition you currently can t merge two forests the relationship between domains domain trees and forests figure 1 shows the relationships between domains domain trees and forests in ad note the 2-way kerberos transitive trust in place between mycompany.com and yourcompany.com a distinguishing feature of ad is that transitive trusts connect all domains within a forest figure 1 ad domains domain trees and forests domain mycompany.com yourcompany.com east.mycompany.com west.mycompany.com sales.yourcompany.com domain tree forest designing the logical namespace is an exercise in deciding how many domains domain trees and forests you need and how to name them if you have an existing nt 4.0 infrastructure that you plan to migrate to ad you must also decide whether to reproduce or improve that domain structure in the new namespace given ad s ability to delegate administration through organizational units ous you should need far fewer domains in win2k than you do in nt 4.0 in addition the need for a new domain is driven less by the need to delegate administration and more by replication and security concerns i discuss these concerns shortly factors other than your existing nt 4.0 domain model will influence your namespace design as you go through the process of deciding how many domains your ad implementation requires and whether you need one or more domain trees or forests you must also consider political and organizational factors geographical factors and technical factors political and organizational factors will your namespace design respect and preserve your organization s existing political boundaries if not you might quickly learn that the fewer domains you want to have the greater your

[close]

p. 9

chapter 1 planning for active directory 3 diplomatic skills must be don t underestimate the political ramifications of collapsing several existing domains into one your ad namespace design should attempt to abstract the organization so that the namespace can weather the vagaries of frequent organizational reshuffling for example if much of your east coast sales department becomes part of the west coast sales department you shouldn t need to move ous or users across domains rather you should be able to simply switch users from one user group to another or from one ou to another another factor to consider is that win2k makes it difficult to rename domains and absolutely impossible to rename the forest root domain so if your namespace depends on the ability to change domain names you ll need to reconsider your approach the technical support model that your company uses centralized or decentralized affects your ou design to create more granular delegation you can either build more ous or use security groups within an ou if you choose to build more ous you potentially increase your effort each time you need to make a change that applies to all ous and you increase the complexity of your ad namespace using security groups to control delegation requires you to thoroughly understand the ad security model and doesn t give you as clear a picture onscreen of where delegation lines are drawn as separate ous do geographical factors if you work for a large multinational company or a company with multinational aspirations try to design your namespace with an eye toward how your ad might grow across national borders how will you handle new acquisitions or separate support organizations technical factors microsoft has done a reasonable job of implementing a full-featured directory service in win2k but some technical challenges remain that will point your ad namespace design in one direction or another i will detail some of these shortly but for now be aware that you should have a good working knowledge of ad s limitations before designing your namespace you might also find yourself designing around certain win2k features for example the way you use group policy objects gpos might influence how you implement your ad namespace at the very least before you finalize your namespace decisions you should know how group policy functions and how it might affect your design domains and forests one or many i ve heard people talk about the nirvana of one ad domain for an entire enterprise some might indeed achieve this dream in win2k but if you don t anticipate getting there anytime soon don t worry just keep the following multiple-domain design considerations in mind keep the forest root empty if you plan to have multiple domains you might want to keep the forest root the first domain you build as an infrastructure container free of production users because this domain has a special role in your infrastructure housing the enterprise admins and schema admins groups reserving it for a few trusted administrators is common.

[close]

p. 10

4 guide to active directory limit trips to other trusts when users access resources in a domain other than the one they belong to they traverse a trust relationship even in win2k and incur a performance penalty thus a multiple-domain design that requires users to make frequent trips across trust relationships can slow response time especially if you create gpos in one domain that users must process from another domain to mitigate performance concerns in a large forest you can create shortcut trusts between frequently accessed domains to reduce the number of hops a cross-domain communication needs to make define a security policy for each domain the domain is still the security boundary in win2k thus you must explicitly define any security policy e.g account lockout behavior password length in each domain you can t define the policy for one domain and expect that policy to protect all domains limit replication between dcs because the domain is a replication boundary you might also need to consider creating new domains to limit the amount of data replicated between dcs especially across slow wan links you can control data replication to some degree through your site design i describe how later but you might need to partition really large domains in any case because of network bandwidth constraints how many forests you should have is an easy question to answer in almost every case you should be driving toward one forest in your production ad infrastructure you might also have a test or development forest that you use to test changes to ad the reasons behind striving for one forest are pretty straightforward win2k today offers no easy way to integrate multiple forests within an environment this will be improved significantly in the .net server product remember that a win2k ad forest shares a common schema a common global catalog gc and common kerberos security trusts if you build a second forest it s a completely foreign environment you must build explicit nontransitive nt 4.0-style trusts to allow sharing between the two forests having multiple forests is especially problematic in environments today that rely on microsoft exchange 2000 server for their email infrastructure as exchange is tightly tied to an ad forest and having multiple ad forests can cause serious email integration challenges sizing dcs after you settle on the namespace s logical layout the next step is to figure out how to physically implement the design this task isn t as trivial as it might sound because at the physical level you need to consider factors ranging from your dcs hardware requirements to the site topology for ad replication along the way you must ensure that your physical implementation takes into account ad s current limitations last you need to consider your dns implementation dns server availability is crucial to proper functioning of ad replication and client logons when sizing your ad dcs you might ask yourself how big is big enough if you decide to collapse 10 nt 4.0 account domains comprising 100,000 users into one ad domain chances are that each dc in the new domain needs more horsepower and disk space than it previously required but how much more microsoft provides a tool for quickly determining your dc requirements see the sidebar active directory sizer for more information.

[close]

p. 11

chapter 1 planning for active directory 5 active directory sizer microsoft s active directory sizer helps you determine the domain controller dc hardware that your active directory ad design will require the tool is available at http www.microsoft.com/windows2000 techinfo/planning/activedirectory/adsizer.asp you specify the number of objects you expect to host in your ad and the number of sites ad sizer also asks for information such as the estimated number of domain logons per second and the frequency of password changes so before running the tool capture some of this data from the security event logs of your current windows nt 4.0 authentication-domain pdcs the nt 4.0 traffic should be fairly representative of the traffic you ll see in your windows 2000 ad infrastructure using the data you enter ad sizer calculates the amount of disk space and ram you need on your dcs and how much traffic you can expect to see going through each of your sites figure a shows sample ad sizer output a domain of 50,000 users and 100,000 computers will generate an ntds.dit file of 2.1gb for this example i specified only one site i could also specify multiple sites and distribute the 50,000 users between the sites and ad sizer would tell me how much network traffic i could expect between the dcs in each site figure a active directory sizer output each new ad object you create requires some disk space on the dc the main ad database file ntds.dit resides on each dc in a domain the more objects and the more object attributes the larger your ad database will be ad is much more scalable than an nt 4.0 domain however an ad database also consumes much more disk space than the nt 4.0 sam because ad includes many more object types e.g volumes group policies and because ad objects can have many attributes e.g user objects can contain phone numbers addresses and email addresses i upgraded an nt 4.0 domain containing roughly 3000 user accounts and machine accounts and

[close]

p. 12

6 guide to active directory several hundred user groups and the resulting ntds.dit file was approximately 38mb using the ad sizer tool i estimated that an nt 4.0 20,000-user domain with multiple extended attributes and that included the use of exchange 2000 would translate to a 500mb ntds.dit file multigigabyte ntds.dit files are common for large or complex ad domains table 1 shows the typical size of a few different types of ad objects a user object with the minimum number of attributes is 3.7kb if you use the microsoft management console mmc active directory users and computers snap-in to create a user the snap-in sets the minimum attributes but you ll probably use many other attributes in your ad objects especially if you plan to implement exchange 2000 table 1 ad objects disk space requirements object additional object attribute based on a 10-character string ou user with mandatory attributes only disk space consumed 100 bytes 1.1kb 3.7kb some less-obvious practices also affect ad size for example each access control entry ace on an ad object s security acl consumes about 70 bytes given the inheritance model that ad uses when applying security you can easily make an acl change that automatically adds new aces to thousands of objects be careful as you delegate control of ad objects in your infrastructure when possible delegate to groups of users rather than to individual users this approach minimizes the number of aces a particular object or attribute requires sites and site links designing a site topology is perhaps the most challenging part of planning an ad implementation before you begin designing you need to be familiar with the ad concepts of sites and site links naming contexts the gc and connection objects sites are ad objects that determine how ad replicates data across your network sites are associated with subnet objects that you define and subnet objects correspond to the tcp/ip subnets in your physical network sites control when and how often dcs replicate with one another dcs within a site i.e intrasite replicate with one another on a fixed schedule every 5 minutes by default dcs across sites i.e intersite replicate on a schedule that you decide upon but no more frequently than every 15 minutes in addition to grouping dcs for the purpose of scheduling ad-information replication sites help workstations and member servers locate resources that are physically close on the network for example a workstation authenticating to an ad domain first examines its own ip address and subnet mask to determine which subnet it s on having determined its subnet and its site through a query to ad the workstation queries dns to find a dc in the same site sites belong to site links groups of sites in which network connections of roughly equal bandwidth link the sites for example figure 2 shows a company with four regional distribution

[close]

p. 13

chapter 1 planning for active directory 7 centers each of the centers has a high-speed lan connecting multiple workstations and dcs a t1 line connects each center to each of the other centers each center is a site but the ad administrator has placed them in the same site link in this case because the connections between the sites have the same bandwidth when you define a site link you can specify a schedule for the sites within that site link and a cost the schedule controls how frequently and at what time replication occurs between sites in the site link and the cost is an arbitrary value you assign to the connections between the sites figure 2 a site link t1 site a t1 t1 t1 site d t1 t1 site b site c all sites in a site link replicate with one another on the same schedule a site can belong to multiple site links which is where the cost metric comes into play in the distribution center example you might add dial-on-demand dod links between two of the centers as a failover precaution you could build a new site link that includes the sites these two distribution centers represent and give it a higher cost than the t1 site link that includes all the distribution centers this action gives ad replication two paths between the two distribution centers the lower cost t1 paths that the sites usually use and the higher cost dial-up paths that the sites use when the t1 lines are out of order naming contexts naming contexts sometimes also referred to as partitions are different paths win2k uses to replicate different types of information between dcs in a forest for each domain in the forest win2k replicates the domain naming context to all the dcs within that domain win2k replicates the schema naming context i.e the ad schema and the configuration naming context i.e site and subnet configuration information and other replication meta data to all dcs in the forest in addition the gc which is a partial replica of all objects in a forest,

[close]

p. 14

8 guide to active directory replicates to dcs that you designate as gc servers the schema and configuration naming contexts contain information that isn t likely to change often for most enterprises so these two naming contexts don t affect your site topology as much as the domain naming context and gc do microsoft supports two replication protocols in ad standard remote procedure call rpc the more common protocol by far supports replicating the three naming contexts and the gc and can compress data for intersite replication standard smtp is only for intersite replication of the schema and configuration naming contexts and the gc smtp is useful for intersite connections that are slow unreliable or even unavailable for large parts of the day however smtp replication sends at least twice as many bytes across your network as rpc replication does you use the active directory sites and services snap-in to define site links and specify which protocol to use for a given site link connection objects after you decide on a site topology win2k creates the replication connections for you ad provides a service called the knowledge consistency checker kcc that runs on all dcs and builds connection objects between all dcs in your forest connection objects handle replication traffic between dcs the kcc builds intrasite connection objects such that no more than three replication hops exist between any two dcs figure 3 shows the active directory sites and services snap-in window with a connection object in the right pane that the kcc generated on servera in the branch site figure 3 a kcc-generated connection object connection objects are one-way paths if you have two dcs each has a separate connection object to the other however if you have large numbers of dcs replicating with one another not all the dcs might have two one-way connections with every other dc a server initiating an intrasite replication event notifies the server at the other end of its connection object that the initiating server has changes the target server then pulls the changed data from the initiating server the kcc also builds connection objects for intersite replication when you create a site the kcc picks a server to act as the bridgehead server for communication between the new site and

[close]

p. 15

chapter 1 planning for active directory 9 remote sites the bridgehead server uses its connection objects to replicate to remote sites at the times you specify in the site link object another server takes over the bridgehead responsibility automatically if the regular bridgehead fails designing a site topology to design an effective ad site topology you need to know how your company will use ad and how the different features in the win2k infrastructure affect replication traffic you can examine how you use your nt 4.0 domains to estimate your ad use for example look at the number of user accounts you create per day the frequency of password changes the average number of users in your user groups and the frequency of user logons your unique traffic requirements should drive your site topology design microsoft can tell you how many bytes of data are generated on the network when you create a new user or when users change their passwords this information is available from resources such as ad sizer and the microsoft windows 2000 resource kit however only you know how often you create new users and how often they change passwords ad replication can take place at the attribute level e.g when a user changes his or her password ad replicates only the password attribute not the entire user object but ad provides many more attributes per object than the nt 4.0 sam provides so depending on how you use objects ad might generate more or less traffic than the sam your site topology design must answer the following questions · at which points do i need to establish site boundaries · how much bandwidth do i need to provide low latency of ad replication · at what point do i need to deploy a local dc instead of having users authenticate remotely earlier i stated that sites control when and how often ad replication takes place intrasite replication takes place at 5-minute intervals intersite replication takes place at 15-minute or longer intervals people often ask how slow a network link between two dcs can be before each controller needs to have its own site no hard and fast rule exists when a link to a remote location becomes saturated with intrasite ad replication and other traffic during typical operations build a new site for one of the dcs and schedule replication at a longer interval intersite replication uses compression when a set of changes to be replicated is larger than 32kb this compression can be very efficient resulting in as much as a 90 percent decrease in data size password changes don t benefit much from compression because they re encrypted after you roughly calculate how much data ad will replicate across your network you can set replication frequency for your site links remember that site links are collections of sites in which the sites are connected by network links of roughly equal bandwidth so if sites a b and c are in one site link they all replicate on the schedule you set for that site link set your replication schedule to take advantage of intersite compression while minimizing latency between dcs for example you might be tempted to set all of your site links to replicate at the minimum interval every 15 minutes to keep latency low however if you don t generate many changes the amount of data transmitted in each replication might not be sufficient to trigger compression and you might end up sending more data per replication event than if you had spaced your replications further apart.

[close]