Over the past several weeks, I've written about migrating from a Windows NT 4.0 domain environment to a Windows 2000 forest. One of the final steps in the migration process entails moving from a Win2K mixed-mode forest to a Win2K native-mode forest. Mixed mode, the default state of a newly installed or newly migrated Win2K forest, allows for the coexistence of Win2K domain controllers (DCs) that rely on multimaster replication and NT 4.0 BDCs that rely on single master replication. This coexistence can occur because of the PDC Emulator, a Win2K DC that acts as an NT 4.0 PDC, sending directory updates to all BDCs. The NT 4.0 PDC is the first DC you upgrade because, by default, it becomes the PDC Emulator.
After upgrading all your DCs to Win2K, you can switch your domain from mixed mode to native mode by opening Active Directory Users and Computers, right-clicking the domain name, choosing properties, and clicking the Change Mode button on the General tab (you can perform the same steps using the Microsoft Management Console— MMC— Active Directory Domains and Trust snap-in). The move to native mode is a one-way process— once you go to native mode, you can’t go back to mixed mode. Before moving, be sure that you won’t need to add an NT 4.0 BDC to your domain in the future. One important note is that DCs are the only machines affected by domain mode, which means you can have NT clients in a native-mode domain or Win2K clients in a mixed-mode domain.
Moving from mixed mode to native mode gives you access to new Win2K group types that can simplify resource access management. NT 4.0 provides two types of groups, local and global. Native- mode Win2K domains offer four different types, called group scopes: local, domain local, global, and universal. In a native-mode Win2K domain, local and global groups function as they did in NT 4.0, with one exception: You don’t use local groups on a DC, only member servers and clients. Because local and global groups are similar in Win2K and NT 4.0, I’ll focus on domain local groups and universal groups.
Domain local groups are available only in a native-mode Win2K domain and are similar to the NT 4.0’s local groups, with one exception: You can use a domain local group to assign permissions to a resource anywhere in the group's domain, not just on the local computer. In NT 4.0, you have to create the local group at the resource’s location (e.g., on each member server with shared network resources). In native-mode Win2K domains, you create a domain local group on any DC and assign local group permissions to that domain for resources that reside on any member machine in the domain. This capability greatly reduces the number of local groups you have to create and simplifies permission assignment.
Universal groups take the concept behind domain local groups a step further by letting you assign permissions not only to a resource within the group’s domain, but within any domain in the forest. You can add user accounts, global groups from any domain, and other universal groups as members of universal groups. So, universal groups can include members from any domain in the forest and have permissions to resources anywhere in the forest. Why would you want to use anything but universal groups? You wouldn’t, if your environment consisted of an entire network connected by high-speed links. You could use universal groups and, instead of managing global groups and domain local groups, place user accounts directly into universal groups and use the universal groups to assign permissions anywhere in the forest. However, without an extremely well connected network, this strategy isn’t a good one.
Unlike global groups and domain local groups, which appear in the Global Catalog (GC) without their members, universal groups and their members appear in the GC. So, whenever universal group membership changes, GC replication traffic results. Because group membership resides in one multivalue attribute, one change will cause the entire membership list to replicate between GC servers. And because you typically have a GC server at each AD site, this replication can occur over WAN links. To avoid this undesirable scenario, place users into global groups and then place the global groups into universal groups. Members of global groups don’t appear in the GC, so you can change membership in the global groups without triggering GC replication events.
Using domain local groups and universal groups can simplify resource access in a native-mode Win2K domain. Once you expose some of the capabilities that these groups enable, you can improve your network security by reducing the number of groups you have to manage.
