Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Domain Design Strategies

In Active Directory, as with classic NT, a

domain defines a discrete security and administrative unit. It also defines a replication boundary, as each domain forms a separate naming context within the Active Directory database.

As you doodle your initial designs, start by looking for ways to use a single Active Directory domain. Do this even if you have a strong feeling that a single domain will not be feasible in your organization due to political turmoil. A single domain has several advantages:

• Easier navigation.
  Users look at network structures with all the fear and suspicion of medieval serfs gaping up at a comet. The simpler you make it for them to find resources, the more likely your design has of being successfully implemented.




• Simpler

  DNS configuration.
  If you have multiple domains in complex parent/child configurations, the resulting DNS zone referrals get a little tricky to configure. DNS causes the majority of Active Directory problems, so it makes sense to avoid complexity when possible.




• Simpler replication topology.
  Managing replication is much more straight-forward in a single domain because you are not mixing different domain naming contexts and Global Catalog servers into your replication topology.

• Eliminate separate Global Catalog servers.
  With a single domain, you eliminate the reliance on separate Global Catalog servers because you can enable the Global Catalog on every domain controller.




• Simpler security implementation.
  It's true that transitive Kerberos trusts make it possible to seamlessly access resources in other domains, but just because a feature is transparent doesn't mean it's simple to manage. An administrator's worst nightmare is trying to resolve a problem with file and directory access permissions by sifting through the membership list for hundreds of groups in separate domains.

Reasons for Using Multiple Domains

You may also encounter sizeable resistance to a single domain on the part of administrators who want an autonomous domain no matter what. I group these objections under

political

restrictions . This is not because I think they are any less important than the technical reasons. They aren't. The stability and performance of an information system has a lot more to do with people than it does with technology. It's just that political design restrictions tend to change considerably during the approval process, so you may be able to apply them less rigorously than the technical restrictions.

There are only a few technical restrictions in Active Directory that may require you to use multiple domains. These include database size, performance restrictions, the need to have unique password policies, and the presence of sites that require Simple Mail Transport Protocol (SMTP) replication.

Database Size Restrictions

The more objects you pack into a single domain, the larger you make the Active Directory database, Ntds.dit, and the more changes you have to replicate between domain controllers. Active Directory can accommodate one billion objects, so you have lots of overhead to play with, but an extremely large database needs more powerful servers to handle authentications and LDAP requests. There comes a point, such as with the Roman Empire, where size affects durability.

An Active Directory database for 100,000 users, their computers, and the groups necessary to manage them would be about 1.5GB. If you add in the additional directory overhead of Exchange 2000, you might touch 2GB. Extrapolating upward, an organization with half a million users would have an Ntds.dit file of 10GB, which is certainly within the capability of an average mirrored or RAID 5 array.

These aren't huge databases by today's standards, so the decision to split into separate domains doesn't really boil down to the number of users and computers and groups. You should be more concerned with replication traffic and acceptable authentication performance.

The vast majority of Windows domains contain fewer than 10,000 users, not enough to make Active Directory breathe hard. The toughest job for the designer of such a system is convincing management not to put additional services on the domain controllers such as messaging or database management. In general, domain controllers work fine when given DNS, DHCP (Dynamic Host Configuration Protocol), and WINS (Windows Internet Name Service) duties, but resist the urge to ladle on other chores. You don't want an application failure to force you into restarting or rebuilding a domain controller.

Only truly gargantuan organizations with many hundreds of thousands of users and computers need to consider dividing their operations into separate domains. Microsoft has not published hard and fast rules about maximum practical database size, so if you are in one of those super-sized organizations, you'll need to work closely with Microsoft Consulting Services to structure your domain.

Performance Restrictions

Most companies deploying Active Directory opt to use separate domains for their overseas operations to reduce the need to replicate across expensive WAN links. This generally means having a Europe domain, a Pacific Rim domain, a South America domain (unless a solid link is available), an Asia domain for China and India, and an Africa domain.

To get acceptable authentication performance, you'll need to size your domain controllers based on the user population in a particular site. If you have a few hundred users in a site who all log on at about the same time in the morning, you can easily get by with a 1U rackmount server with a single Xeon processor, 256MB of memory, a 100Mbps network card, and mirrored drives to hold the Active Directory files. Such a server costs less than $4,000 from top-tier vendors.

If you have several thousand users authenticating in the morning at the same site, you can spread out the load by installing several smaller domain controllers or beef up a few domain controllers with dual processors, multiple network adapters, and separate mirrored spindles for the Active Directory and Sysvol files.

Password Policy Restrictions

Three sets of policies affect attributes of the Domain object in Active Directory and cannot be modified by group policies in subordinate containers like OUs. They are as follows:

• Password policies.
  These include maximum and minimum password age, minimum password length, password history, complexity requirements, and reversible password storage.




• Account lockout policies.
  These include the number of bad attempts that trigger a lockout, lockout duration, and reset interval.




• Kerberos policies.
  These include service and user ticket lifetimes, ticket renewal interval, and permissible clock skew.

If these policies must have different settings within the same organization, you'll need to create separate domains. This might happen if you are working on a contract and the client wants you to have certain security restrictions that are different than those in your organization.

SMTP Replication Restrictions

You may have a site or sites in remote, forsaken corners of the world like Tierra del Fuego or Hobbs, New Mexico. The network links to these sites might not be able to maintain stable data communications. If you attempt to construct a standard inter-site low-speed RPC connection over these links, the connections may fail often enough to prompt the bridgeheads to give up.

If this happens, you can use Simple Mail Transport Protocol (SMTP) as the transport for replication to the remote site.

SMTP is well suited for transporting replication packets over unreliable connections, but it has limitations when it comes to security. The RPCs used for inter- and intra-site replication encrypt traffic, but SMTP traffic is transferred in the clear. To avoid potential compromise of secure Active Directory information, the messages are encrypted using a form of secure messaging. This requires a Domain Controller certificate at the bridgehead servers on either side of the connection. To get this certificate, you'll need a Microsoft Certification Authority.

Another limitation when using SMTP lies with the File Replication Service, or FRS. This service replicates the content of Sysvol, which contains group policy template files and the files used for classic system policies and scripting. FRS cannot use SMTP. This means that group policy container objects in Active Directory will not stay in sync with group policy files in Sysvol. For this reason, you cannot use SMTP to connect bridgeheads in the same domain.

Political Restrictions

A single domain should work for all but the largest and most geographically diverse organizations. As we get further into the operation of authentication, rights delegation, group management, and group policies, you'll see that it is entirely possible to build a single domain with Organizational Units to define management and administrative boundaries.

Still, a good single-domain design can fracture during the approval process, usually because of balkanization rather than any engineering limitations. System administrators and their managers may view domain consolidation with suspicion. Depending on your personal force of will and your backing from management, you may end up with more domains than you really need.

Try not to let local administrators carry their independence too far at the expense of reliability and performance. Large numbers of domains, especially when they each comprise a separate tree in the forest, complicate replication and domain controller placement.

If you are a local administrator facing an initiative by central IT to consolidate domains, try to rein in your suspicions. You can get wide operational latitude in an OU and still share the benefits of a single Active Directory structure.

Figure 8.4 shows an example of a forest where global regions have been compartmentalized into separate domains and large offices have been made into domains rather than OUs. The company has separate business units that also insisted on being in separate domains.

Administratively, this structure becomes unwieldy because it forces you to manage many different Domain naming contexts with many possible variations of OUs and group policies. If your organization has no central IT staff whatsoever, this structure might work for you. Otherwise, you should try to avoid proliferating separate domains below major geographical areas.

Multiple Domains and Groups

IfChapter 12, "Managing Group Policies," takes a detailed look at security group functionality, but let's take a sneak preview right here to find out what we need to know for domain design. Here are the important elements to watch out for:

• There are three different group types in Active Directory and their membership and application scopes differ. You must be in Native to get maximum flexibility.




• The security subsystem uses groups to determine access authorization. If you do not plan correctly, users might be unable to reach certain resources, or you might be unable to lock them out.




• Membership lists for the various group types are stored differently in the Global Catalog. This makes access to a GC a highly important element of your Active Directory design.

Group Classifications

Active Directory recognizes three classes of security groups: Domain Local, Global, and Universal. A fourth type, Machine Local, is only present in the local SAM of a member computer.

Groups are differentiated by their scope of membership and scope of use:

• Domain Local.
  This group type can have members from any domain in the forest. It can only be assigned to access control lists (ACLs) within its own domain.




• Global.
  This group type can have members only from its own domain. It can be assigned to ACLs anywhere in the forest.




• Universal.
  This group type can have members from any domain in the forest. It can be assigned to ACLs anywhere in the forest.

Group Nesting

Groups can be nested in other groupsthat is, one group can be a member of another group. Nesting rules restrict which group type can be a member of another group type. The nesting rules vary depending on whether the domain is Mixed or Native. Here are the nesting rules:

• In Mixed, Domain Local groups cannot nest within other groups. In Native, Domain Local groups can nest in other Domain Local groups in the same domain but not in any another group type. Domain Local groups can never nest in groups in other domains.




• In Mixed and Native, Global groups can nest in Domain Local groups. In Native, Global groups can nest in other Global groups and Universal groups.




• Universal groups can only be created and used in Native. They can nest into Domain Local, Global, and other Universal groups. If you have users from several domains in a Universal group, you can still nest the Universal group into a Global group as long as the two are in the same domain.

A user's group membership helps determine which resources the user is authorized to touch. The group nesting rules determine how hard a user's logon server has to work to determine the user's group membership.

Groups and Authorization

When a user logs on, the Local Security Authority Subsystem (LSASS) at the logon server constructs a

Privilege Access Certificate , or PAC, for the user. The PAC contains the user's Security ID (SID), a batch of security policies (password length, password history, logon time restrictions, and so forth), the SID of every group to which the user belongs, and the SID of

any groups to which those groups belong .

I emphasized the last part of that sentence because the way groups nest together has an impact on how you design your domains and lay out your security structures. Here's an example.

Let's say that the security descriptor for a particular folder has an access control list (ACL) containing entries for two groups. Group A has Deny All permissions. This means that every member of group A is denied access. Group B has Full Control permissions. This means that every member of group B can create, read, write, modify, and change the security descriptor of files in the folder.

If you nest group B into group A, all members of group B are suddenly denied access. The most restrictive permission has precedence.

To make this nesting trick work, LSASS must chase down all cascading group memberships so that the user's PAC contains every applicable SID. This brings us to the final distinction between security groups.

A Group object has an attribute called Member. This attribute contains the distinguished name (DN) of each group member. When you add a user or another group to the membership list of a group, you add the user or group's DN to the Member attribute. The Active Directory stores the Member attribute for a group differently depending on the group type:

• A standard domain controller holds the Member attribute for all Group objects in its domain: Domain Local, Global, and Universal.




• The Global Catalog stores the Member attribute for Universal groups from all domains in a forest.




• The Global Catalog does not store the Member attribute for Domain Local and Global groups.

Microsoft chose to exclude Domain Local and Global group membership from the GC to conserve replication bandwidth. The reasoning goes like this:

• Universal groups can be nested into groups in other domains. Those groups can be placed on ACLs in any domain. For this reason, the LSASS must chase down cascading group memberships for Universal groups. To avoid walking the tree each time a domain controller performs this search, the Universal group Member attribute is included in the Global Catalog.




• Domain Local groups cannot be nested into groups in other domains. When the LSASS assembles a PAC, it does not need to chase down any cascading group memberships in other domains because there cannot be any. It can get all the information it needs from the local Domain naming context. Therefore, it is not necessary to store Domain Local group membership in the Global Catalog.




• Global groups can be nested into Domain Local and Universal groups in other domains. Domain Local groups cannot be placed on ACLs outside their own domain, so there is no need to chase down those cascading memberships. Universal group membership is already included in the Global Catalog. So, for Global groups, the LSASS can get all the information it needs from searching the local Domain naming context. It is not necessary to store Global group membership in the Global Catalog.

Summary of Groups and Active Directory Design

As you can see, group interaction in a multi-domain forest can get complex. The complexity grows if you decide to use Exchange 2000 as your messaging platform because security groups control access to public folders. Also, Exchange makes use of a second group type called the Distribution group to create email distribution lists without security credentials.

Here are key points to keep in mind regarding groups when you lay out your Active Directory design:

• Changing the membership of a Universal group results in a replication event to every Global Catalog server in the forest. If you define different domains for large geographical areas such as North America, Europe, Pac-Rim and so forth, you will incur additional communication traffic if the Universal group members change frequently. For this reason, Microsoft recommends putting users in Global groups and nesting Global groups into Universal groups.




• Universal groups and the advanced nesting rules for Global groups are only available in Native, so your design should make the transition from classic NT as simple and quick as possible.




• The user's logon server must be able to determine the user's Universal group membership to properly construct the user's Privilege Access Certificate. To prepare for a potential loss of a GC server, you should either configure multiple GC servers in a site or configure a standard DC to cache the GC contents.

If you use multiple domains, it's imperative that you develop a set of standards for your operations and administration staff to define the group types to create for various situations. Otherwise, you'll soon have a mishmash of group types that makes chasing down resource access permissions very difficult.

Designing Trusts in Multiple Domain Forests

If you must have more than one domain, you need to decide how you will structure the trusts between the domains. You have several choices depending on how you plan on doing business over the next few years:

• Tree.
  You'll get the most straightforward structure by confining your domains to a contiguous namespace, forming a tree. Individual domains in the tree trust each other using a Parent/Child trust. This simplifies your LDAP searches and makes scripting more straightforward, as well. It also simplifies user management, because individual objects can be quickly and easily moved between OUs.




• Forest.
  If you cannot configure your DNS namespace to accommodate a single, contiguous tree, your next most effective solution is a forest of trees. Conglomerates and universities often select this structure because they have a diverse, decentralized IT organization. Each business unit or college gets its own top-level domain with its own DNS root. The root domains trust each other using a Tree Root trust. The child domains participate in the trust thanks to transitive, two-way Kerberos authentication.




• Federation.
  If you cannot convince your colleagues to merge their separate domains into a single forest, you can achieve something approaching a single security entity using a Forest trust between the root domains in each forest. This trust type supports transitive two-way Kerberos authentication, which simplifies user access to resources. A Forest trust is

  not a replacement for a true Tree Root trust. The two forests represent completely separate administrative entities and you cannot easily move objects between them. You also cannot write simple scripts to manage the two forests. The Forest trust is most advantageous in situations where you must quickly build a security structure then wait a while before consolidating the objects into a single forest.




• Mixed Domains.
  If you have downlevel NT domains, Samba domains, or MIT Kerberos v5 realms that you want to integrate into your Active Directory architecture, you can form External trusts or Realm trusts. You can also form External trusts to Active Directory forests with which you cannot form a Forest trust. Realm trusts can be two-way and transitive. External trusts are always one-way and intransitive.

Configuring Logons for Multiple Domains

If you have a single global domain, users can travel from Phoenix to Seoul, sit down at a workstation, press Ctrl-Alt-Del, and log on with their standard credentials. The local domain controller in Seoul has a replica of the same Domain naming context as the domain controller in Phoenix.

If you have multiple domains, though, you need to train your traveling users to use one of two approaches:

• Select their home domain from the Winlogon pick list. This requires users to remember their home domains, which might be something of a feat for a user who scarcely remembers a password. Also, the standard Winlogon window doesn't show the domain pick list by default. You have to click the Options button.




• Log on using their UPN (User Principal Name). An example would be tjones@company.com. As soon as the Winlogon window sees an @ sign in the user name, the Domain pick list is dimmed.

The system behaves exactly the same whether the user logs on using a UPN or a flat name with a domain. The user authenticates using Kerberos in an Active Directory domain and NTLM Challenge-Response in an NT domain. Using the UPN does not cause a client to "seek out" an Active Directory domain controller in a mixed-mode domain. The only difference is that the UPN logon requires a lookup at a Global Catalog server to "crack" the string into its component parts of username and domain. When you create a Parent/Child domain trust using a contiguous DNS namespace, the child domain is automatically configured to use the UPN of the root domain in the tree. The same is not true for forests where the domains or domain trees occupy a discontiguous DNS namespace.

You can use a UPN logon to your advantage in a Discontiguous forest by assigning a custom UPN Suffix that all users in a forest can use so they don't need to know their home domain. If you select flat names that correspond to the users' email mailboxes, the logon names and email names would be the same. This is nowhere near a single sign-on solution, but it simplifies the user experience with two of the major systems that require authentication.

By assigning a custom UPN Suffix, you can have a universal logon structure to simplify training. However, you must be sure to keep the flat names unique in the various domains. If you attempt to assign a flat name that already exists in another domain, the domain controller will query a Global Catalog server to verify that the name is unique. If a GC server is not available, you will not be permitted to create the potentially non-unique name. Assign a custom UPN Suffix using the AD Domains and Trusts console as described in Procedure 8.1.

set OU = GetObject("LDAP://ou=Phoenix,dc=Company,dc=com")
OU.filter = Array("User")
NewUPNSuffix = "@BigCompany.com"
For Each User in OU
Wscript.echo "Current UPN: " & User.UserPrincipalName
Wscript.echo "Current logon name: " & User.SamAccountName
User.UserPrincipalName = user.SamAccountName & NewUPNSuffix
User.Setinfo
Wscript.echo "New UPN: " & User.UserPrincipalName
Next

Procedure 8.1 Assigning Custom UPN Suffixes

1. Right-click the AD Domains and Trusts icon and select P

   ROPERTIES from the flyout menu. The Properties window opens as shown in Figure 8.5.

   Figure 8.5. AD Domains and Trusts Properties window showing UPN Suffixes tab.

   

2. There is only one tab in the Properties window, UPN Suffixes. Enter the suffix in the Alternative UPN Suffixes field and click Add.

3. Click OK to save the change and close the window.