You should always ask yourself two questions when dealing with Group Policy: Show
The LSD OU rule ^With these two questions, you will be able to understand how the system applies Group Policy Objects as well as which object you are attempting to add or remove settings to. Additionally, a simple acronym can help anyone understand the layering of GPOs. That acronym is LSD OU! It stands for the following elements: L = Local S = Site D = Domain OU = Organizational Unit You can create and apply GPOs to computers and users, but most people think they only apply to domains. This is partially true, but you can configure Group Policies for local machines as well. This means you can apply GPOs in multiple ways, but GPOs will apply to a system or user in a specific order. This specific order is the same as in the acronym: LSD OU.  LSD OU rule: L (local), S (site), D (domain), OU (organizational unit) Local Group Policy ^On your local system, you can view and edit your Local Group Policy settings by searching your computer. Using the Start Menu, begin typing (searching) for "Edit Group Policy." You can configure settings for your local system or account, but all subsequent Group Policy layers (site, domain, and OU) that have the same setting configured or enabled can overwrite these settings. This means you can configure Group Policies locally, but the system can overwrite them when you've set Group Policies to trump these settings from site, domain, or OU GPOs applied to your system or user account. Site-based Group Policy ^Now that we understand how Windows applies Local Group Policy settings, we move toward understanding how an organization that has Active Directory (AD) can apply GPOs. At the topmost layer, Group Policy Objects can apply to the "site" level. To understand how a site-based Group Policy could work, we must first generally understand how large organizations might structure their environment. In Active Directory, we have a topmost layer called an AD forest. An organization can have multiple forests. Within each AD forest, we can have multiple domains. Multiple AD forests and domains If your organization has a large environment, the infrastructure design may look like the figure above. Even if you only have one domain in your environment, you can use AD sites, but you will not typically see this. You can understand an AD site as a subnet of your network. We can organize or group machines, systems, users, etc. that reside within a specific subnet. We can then apply a specific GPO to those objects even if those items do not reside in the same domain (or even forest). Some organizations may use this feature. I have never had to use it personally, but it's a great way to organize your GPOs across domains and forests, especially for servers that may reside in your datacenter but belong to different groups, sub-organizations, or domains. When linking GPOs to your sites (groups) and a Local Group Policy exists with the same setting, site-based GPOs will overwrite any Local GPO settings. Domain-based Group Policy ^Domain based Group Policy Objects are far more common in organizations, mostly because setting up a new domain creates a "Default Domain Policy" at the root of that domain. This policy contains a few default settings like a password policy for your users, but most organizations change these. Additionally, some organizations modify this default policy and add their own specifications and settings. You can definitely add to and edit the Default Domain Policy, but you may be better off just creating a new GPO at the root of your domain. If you decide to modify the existing Default Domain Policy or create a new GPO, please be aware you should apply certain settings to your root domain and not subsequent locations like OUs. It is possible to set these settings in alternate locations, but not recommended. You can only set these settings once per domain, and thus the best practice is to apply these at the root of the domain.
If you have a specific configuration or setting you want to apply to all systems, you should create and link that GPO to the root of your domain. This aids both visually and logically the design and layout of your GPOs. If you still want to apply a GPO to most of your systems or users, you can still create and link that GPO to the root of your domain. However, you will need to filter what the GPO will apply to. You can filter a GPO several different ways, but the most common methods are using the Security Filtering sections on the GPO's Scope tab or using WMI Filtering (also located on the Scope tab). By default all GPOs have Authenticated Users set as the filtering scope. (Please note Authenticated Users means both user and computer objects authenticated to the domain.) But if you wish, you can specify both (or either) a Security, Distribution, or individual objects that contain either computers or users, instead of all Authenticated Users. As I mentioned previously, you can also set a WMI Filter that will automatically filter what objects this GPO will apply to. For example, if I wanted to apply a GPO to all laptop and mobile computers, I could add a WMI filter that would look for the existence of a battery. WMI filter to apply a GPO only to systems with a battery Group Policies applied at the domain level will apply to all objects that contain the specific setting you have configured. Applying either a local or site policy that includes an object (user or computer) within our domain will apply those settings first. If we set a domain-wide policy that has any portion of either a local or site GPO, our domain GPO will overwrite either of the previous settings. In a typical organization, you will always see Account, Account Lockout, and Kerberos Policies at the root of that domain, but some choose to add other policies. For example, one could configure and add settings related to Windows Event Viewer logging across all systems. It is a best practice to create a specific policy for this setting instead of just adding it to the Default Domain Policy (but you can). Most of your GPOs (configurations) will apply one step lower, at the Organizational Unit level. This allows for more granular control, and visually these OUs typically represent the structure of your organization (e.g. Finance, HR, Marketing, etc.). Container-based Group Policy ^Depending on who has designed or organized your Active Directory OU structure, you will typically have a set of containers or folders similar to the layout of a file system. These folders (OUs) can contain any AD object like Users, Computers, Groups, etc. Even though they contain these objects, all Group Policy Objects contain built-in filtering. When we create a new GPO, we will see there are two main configuration options available (built-in filtering). These are Computer Configuration and User Configuration. We can apply configurations to both Users and Computers within the same GPO, but we can also specify one or the other as well. User and Computer based Group Policy For example, let's imagine we have a simple setup for our domain that contains the following: Example of Group Policy order in a simple organizational structure The Default Domain Policy will apply to all OUs and User or Computer objects that reside below where you applied the GPO (basically, in the domain). Again, typically this GPO contains all the Account, Account Lockout, and Kerberos settings for the entire domain and possibly other configurations and settings. The second layer (Parent OU) has a Group Policy applied to it called Configure Default Logging, which applies to all Computer objects that reside within the Parent OU. This means that the Configure Default Logging policy will apply to any computers within either the Parent OU or Child OU. The last layer is the Child OU. This OU has another GPO applied to it called Configure Child Default Logging. The Configure Child Default Logging GPO could be the same as the Configure Default Logging GPO. (You shouldn't do this, but if you have a reason to, you can.) But let's imagine we have decided to change the Retain application log setting for all computer objects residing under the Child OU. However, we don't want to apply it to all computer objects within the Parent OU. This means our Default Domain Policy will apply first to our computer. (Remember, you can specify certain settings only once and thus only apply them once). Next the settings of our Configure Default Logging policy will apply to our computer. Finally, our changes to Configure Default Logging in our Configure Child Default Logging policy will apply last. This will modify any settings that are not "set only once" settings and are within the Configure Default Logging policy. The order in which these GPOs will apply to our computer objects is as follows: Default Domain Policy > Configure Default Logging > Configure Child Default Logging There are a few caveats to this processing though. These are longer topics, which I plan on writing more about soon, but these caveats include both Enforced and Block Inheritance. A GPO applied higher in the hierarchy of your AD (OU) structure has the right to enable a setting on that GPO called Enforced. Enforced means that if any other OUs have enabled another setting (which I'll talk about next) called Block Inheritance then that GPO will apply no matter what (even with Block Inheritance enabled). A GPO higher in the domain or OU structure that has Enforced enabled will overwrite any subordinate OUs that have enabled Block Inheritance. To enable the Enforced setting on your GPO, you can right-click it and select Enforced. Enforcing a GPO To add Block Inheritance to an OU, you can select it, right-click it, and select Block Inheritance. Again, if certain settings like Account, Account Lockout, and Kerberos policies already apply, those settings will trump either one of these features since they only can apply once across your domain. Block inheritance of GPOs to specific OUs to influence GPO order Conclusion ^Remember the two main questions you should always ask yourself before enabling a Group Policy Object:
Understanding these two questions is critical when you begin configuring GPOs that may impact hundreds or even thousands of users or computers in your organization. Additionally, if you understand LSD OU, you are well on your way to mastering Group Policy order and streamlining your IT processes.
|
List the order of group policy processing, starting with the policies, which are processed first.
Postagens relacionadas
direito autoral © 2024 aprendervalor Inc.
