Having taught Windows 2000 classes for 2 years, I hear some questions and comments repeatedly. For example, students sometimes create test user accounts to experiment with a certain feature. However, when they try to log on as the new user, they can't because normal domain users don't have permission to log on locally to a domain controller. In the dozens of Win2K classes that I have taught, I have yet to see one student figure out how to correctly assign the log on locally right the first time, no matter how much NT 4.0 experience he or she has. Their natural instinct, as was mine, is to log on as an administrator and locate the tool that we use to assign user rights in NT 4.0, User Manager for Domains. Only this isn't NT 4.0, so they look for user rights in the tool that replaced the NT tool's basic functionality, Active Directory Users and Computers.
If they know that Group Policy now controls user rights, along with most other configuration settings, most users still can't make the change effective on the first attempt because they edit the wrong Group Policy Object (GPO). When I demonstrate how and where to make the change, I always hear some variation of the same statement: "This was so much simpler in NT 4.0—why did Microsoft have to make it so complicated?"
What Is Group Policy?
Group Policy is a central component of Microsoft’s change and configuration strategy for Win2K. With Group Policy, you can define users’ environments and system configurations from one location. The settings you can control with Group Policy include environmental settings, user rights assignment, account policies, folder redirection, script assignment, security settings, and software distribution. In other words, you can control everything from what desktop components users have access to, and where they save files, file system and Registry permissions, and Internet Explorer (IE) settings, to what software installs on each Win2K machine in your forest and what software is available for each user to install optionally. As you can see, Group Policy provides tremendous capabilities, and if you understand it and implement it correctly, it can be very useful.
Group Policy vs. System Policy
At first glance, many users think that Group Policy is like NT 4.0’s system policies, but with more capabilities. However, several differences exist. System policies are useful for setting user desktop configurations by controlling Registry settings, while Group Policies have much broader configuration capabilities. When you use a system policy to set a Registry configuration, the Registry setting is persistent, meaning that even if you remove the policy, the setting remains until you change it manually or overwrite it with another policy. Group Policy’s Registry configurations aren't persistent; the system removes and rewrites the settings whenever any policy change occurs. You create system policies at the domain level, and they apply to users based on group membership. Group Policies apply to users and computers depending on where they reside in the Active Directory (AD); security groups only filter Group Policy.
How Group Policy Applies
As I mentioned, Group Policies are applied based on a user's or computer's location in the AD container hierarchy. Specifically, you apply Group Policies to sites, domains, and organizational units (OUs). If a Group Policy's settings apply to one of these AD containers, then by default, those settings apply to every user and computer object in that container. Users and computers belong to a site, domain, and OU at the same time, so it's important to know that the order in which AD processes GPOs is by site, domain, and OU. By default, if conflicting settings exist in each of these containers, the last one processed is the setting that applies—in other words, the OU settings. In the case of nested OUs, AD processes the GPOs from parent container to child container. So, if you have an OU named North America and an OU named Sales within it, AD will process the Sales GPO after the North America GPO. If any conflicts exist, the Sales GPO’s settings will apply because it's the last one that AD processes. Although this order is the typical process in which AD applies Group Policy, you can change this behavior by configuring either Block Inheritance or No Override. If you apply both settings at different container levels within AD, No Override takes precedence over Block Inheritance. As you can see, it's important to design your AD with Group Policy in mind. Otherwise, you'll have an implementation that's very difficult to administer and troubleshoot.
So, how do we give users the right to log on locally to a domain controller? An AD domain has two built-in GPOs: Default Domain Policy, which applies to the domain, and Default Domain Controllers Policy, which applies to the domain controller's OU. Using the Group Policy Editor (GPE) Microsoft Management Console (MMC) snap-in, we would focus the snap in on the Default Domain Controllers OU because that's where the domain controller’s computer object resides.
You're probably still wondering why Microsoft had to make this so complicated. As we delve deeper into Group Policy in the next few weeks, I'll provide you with some answers.
