Newbie Group Policy Question

bluesjunior23

Hey guys: When we speak of local group policy objects (lgpo), i have understood this to mean that the policy only applies when a user logs in to the local computer. However, does this mean when the user selects "local machine" when loging in at the login screen or when they login to a specific computer on the domain? Thanks fellas!

Mishra

It applies to both methods of logging in, locally or on the domain. However if you have GPOs applied to that computer from AD level then it overrides any local policy setting you have on your machine.

Mishra

I gathered a little information for you. I actually found this by click start/run typing in gpedit.msc, right clicking local computer policy, clicking help, then selecting Local Group Policy objects. This explains it in a different way that may be a little easier to understand.


Local Group Policy objectsThe local Group Policy object (local GPO) is stored on each individual computer, in the hidden %systemroot%\System32\GroupPolicy directory. Each computer running Windows 2000, Windows XP Professional, Windows XP 64-Bit Edition, or Windows Server 2003 has exactly one local GPO, regardless of whether the computers are part of an Active Directory environment.

Limitations of the local Group Policy object
Local GPOs do not support certain extensions, such as Folder Redirection or Group Policy Software Installation. Local GPOs do support many security settings, but the Security Settings extension of the Group Policy Object Editor does not support remote management of local GPOs. Thus, for example, the command line gpedit.msc /gpcomputer:"Computer1" will allow you to edit the local GPO on Computer1, but Security Settings will not appear.

Local GPOs are always processed, but are the least influential GPOs in an Active Directory environment, because Active Directory-based GPOs have precedence.

For more information about the Group Policy extensions that differ in the local GPO as compared with Active Directory-based GPOs, see Folder redirection, Software installation, and Security settings.

Related Topics

bluesjunior23

Thanks for your replys so far! Ok here is my first response: (I am a newbie so I am more than likely misunderstanding you Mishra but here goes!

"However if you have GPOs applied to that computer from AD level then it overrides any local policy setting you have on your machine."

However, I have read that the tiers related to group policy are as follows:

1.Local GP
2.Site GP
3.Domain GP
4. OU GP

Does this mean that the Local GP overides the lower tiers? If not then why is it listed as the top tier?


Thanks for your help!

Mishra

adam21983 wrote:

Thanks for your replys so far! Ok here is my first response: (I am a newbie so I am more than likely misunderstanding you guys but here goes!

"However if you have GPOs applied to that computer from AD level then it overrides any local policy setting you have on your machine."

However, I have read that the tiers related to group policy are as follows:

1.Local GP
2.Site GP
3.Domain GP
4. OU GP

Does this mean that the Local GP overides the lower tiers? If not then why is it listed as the top tier?


Thanks for your help!

Nope, it is the other way. OU GPs override Domains which override sites which override local.

bluesjunior23

OK I think I get it now... So in other words the tier order that I described defines how the policies are distributed, ie: policy applied to a domain is pushed down to the OU's in the domain. And the tier order that you described would define what policy settings would take precedent. In other words policy applied to an OU would override policy applied to the domain that contained that OU?!!

Thanks!

famosbrown

The only way to get a Local Policy to override a Policy from AD is to enable Loopback Processing and this will replace the User portion of the AD GPO with the User portion of the Local GPO...unless you decide to merge them together instead.

Mishra

famosbrown wrote:

The only way to get a Local Policy to override a Policy from AD is to enable Loopback Processing and this will replace the User portion of the AD GPO with the User portion of the Local GPO...unless you decide to merge them together instead.

Hmm.. Loopback modes don't have anything to do with local policy. Loopback mode is designed to select which user and computer settings you would like from the OUs the the computer and user object are located.

I posted a topic talking about how it works.

http://www.techexams.net/forums/viewtopic.php?p=174442#174442

dynamik

famosbrown wrote:

The only way to get a Local Policy to override a Policy from AD is to enable Loopback Processing and this will replace the User portion of the AD GPO with the User portion of the Local GPO...unless you decide to merge them together instead.

That's not correct. Loopback processing doesn't have anything to do with where the policy is applied (local, domain, site, ou). In a nutshell, loopback processing allows user settings to be applied to a computer. Here is a link that goes into detail: http://technet2.microsoft.com/windowsserver/en/library/abe2b1a9-975f-4b2f-b771-9e6a903e97db1033.mspx?mfr=true

famosbrown

Being that I've used Loopback Processing intensively, I would have to disagree with you both regarding what I posted.

I posted that in order to have a Local Policy override ANY AD GPO, you would have to enable Loopback Policy within the Local Policy of the specific computer. Again...this is for the user setting. I've used this extensively, as we have strict user policies and some of the users in org needed certain unrestricted user priviliges on certain computers. We also use the Looback Policy for Local Computer Policies in a couple of kiosks computer areas to meet other business requirements.

famosbrown

Mishra wrote:

famosbrown wrote:

The only way to get a Local Policy to override a Policy from AD is to enable Loopback Processing and this will replace the User portion of the AD GPO with the User portion of the Local GPO...unless you decide to merge them together instead.

Hmm.. Loopback modes don't have anything to do with local policy. Loopback mode is designed to select which user and computer settings you would like from the OUs the the computer and user object are located.

I posted a topic talking about how it works.

http://www.techexams.net/forums/viewtopic.php?p=174442#174442

I checked out your post, and I was a little confused like the person who replied as well, but I think I understand what you were trying to work out...in your examples, you are still stuck in the AD GPO's and not working in Local GPO. You were "demonstrating" how Loopback Processing works when enables with the AD GPO's (Site, Domain, OU).

dynamik wrote:

famosbrown wrote:

The only way to get a Local Policy to override a Policy from AD is to enable Loopback Processing and this will replace the User portion of the AD GPO with the User portion of the Local GPO...unless you decide to merge them together instead.

That's not correct. Loopback processing doesn't have anything to do with where the policy is applied (local, domain, site, ou). In a nutshell, loopback processing allows user settings to be applied to a computer. Here is a link that goes into detail: http://technet2.microsoft.com/windowsserver/en/library/abe2b1a9-975f-4b2f-b771-9e6a903e97db1033.mspx?mfr=true

Read what you linked and try to find some more detailed information. It is used to replace or merge user settings set in a particular GPO whether it be OU or Local...as the article stated, it's used in kiosks, laboratories, etc....I've usually seen these type of public places configured with Local Policy with Loopback Policy Merge or replace enabled.

dynamik

famosbrown wrote:

Read what you linked and try to find some more detailed information. It is used to replace or merge user settings set in a particular GPO whether it be OU or Local...as the article stated, it's used in kiosks, laboratories, etc....I've usually seen these type of public places configured with Local Policy with Loopback Policy Merge or replace enabled.

Here is some excerpts from this link: http://support.microsoft.com/?id=231287

MS KB wrote:

SUMMARY
Group Policy applies to the user or computer in a manner that depends on where both the user and the computer objects are located in Active Directory. However, in some cases, users may need policy applied to them based on the location of the computer object alone. You can use the Group Policy loopback feature to apply Group Policy Objects (GPOs) that depend only on which computer the user logs on to.

MS KB wrote:

When users work on their own workstations, you may want Group Policy settings applied based on the location of the user object. Therefore, we recommend that you configure policy settings based on the organizational unit in which the user account resides. However, there may be instances when a computer object resides in a specific organizational unit, and the user settings of a policy should be applied based on the location of the computer object instead of the user object.

Note You cannot filter the user settings that are applied by denying or removing the AGP and Read rights from the computer object specified for the loopback policy.

Normal user Group Policy processing specifies that computers located in their organizational unit have the GPOs applied in order during computer startup. Users in their organizational unit have GPOs applied in order during logon, regardless of which computer they log on to.

In some cases, this processing order may not be appropriate. For example, when you do not want applications that have been assigned or published to the users in their organizational unit to be installed when the user is logged on to a computer in a specific organizational unit. With the Group Policy loopback support feature, you can specify two other ways to retrieve the list of GPOs for any user of the computers in this specific organizational unit:

•Merge Mode
In this mode, when the user logs on, the user's list of GPOs is typically gathered by using the GetGPOList function. The GetGPOList function is then called again by using the computer's location in Active Directory. The list of GPOs for the computer is then added to the end of the GPOs for the user. This causes the computer's GPOs to have higher precedence than the user's GPOs. In this example, the list of GPOs for the computer is added to the user's list.

•Replace Mode
In this mode, the user's list of GPOs is not gathered. Only the list of GPOs based on the computer object is used.

The point I was trying to make is that describing loopback processing simply as a way to have local GPOs override AD GPOs is misleading and not technically accurate. Looking at your original post, I see that you were not providing a definition of loopback processing as much as you were detailing a scenario. I apologize my miscommunication/misunderstanding.

famosbrown

dynamik wrote:

famosbrown wrote:

Read what you linked and try to find some more detailed information. It is used to replace or merge user settings set in a particular GPO whether it be OU or Local...as the article stated, it's used in kiosks, laboratories, etc....I've usually seen these type of public places configured with Local Policy with Loopback Policy Merge or replace enabled.

Here is some excerpts from this link: http://support.microsoft.com/?id=231287

MS KB wrote:

SUMMARY
Group Policy applies to the user or computer in a manner that depends on where both the user and the computer objects are located in Active Directory. However, in some cases, users may need policy applied to them based on the location of the computer object alone. You can use the Group Policy loopback feature to apply Group Policy Objects (GPOs) that depend only on which computer the user logs on to.

MS KB wrote:

When users work on their own workstations, you may want Group Policy settings applied based on the location of the user object. Therefore, we recommend that you configure policy settings based on the organizational unit in which the user account resides. However, there may be instances when a computer object resides in a specific organizational unit, and the user settings of a policy should be applied based on the location of the computer object instead of the user object.

Note You cannot filter the user settings that are applied by denying or removing the AGP and Read rights from the computer object specified for the loopback policy.

Normal user Group Policy processing specifies that computers located in their organizational unit have the GPOs applied in order during computer startup. Users in their organizational unit have GPOs applied in order during logon, regardless of which computer they log on to.

In some cases, this processing order may not be appropriate. For example, when you do not want applications that have been assigned or published to the users in their organizational unit to be installed when the user is logged on to a computer in a specific organizational unit. With the Group Policy loopback support feature, you can specify two other ways to retrieve the list of GPOs for any user of the computers in this specific organizational unit:

•Merge Mode
In this mode, when the user logs on, the user's list of GPOs is typically gathered by using the GetGPOList function. The GetGPOList function is then called again by using the computer's location in Active Directory. The list of GPOs for the computer is then added to the end of the GPOs for the user. This causes the computer's GPOs to have higher precedence than the user's GPOs. In this example, the list of GPOs for the computer is added to the user's list.

•Replace Mode
In this mode, the user's list of GPOs is not gathered. Only the list of GPOs based on the computer object is used.

The point I was trying to make is that describing loopback processing simply as a way to have local GPOs override AD GPOs is misleading and not technically accurate. Looking at your original post, I see that you were not providing a definition of loopback processing as much as you were detailing a scenario. I apologize my miscommunication/misunderstanding.

If you look at the first post few posts of this thread, Local Policy's is asked about. I simply giving a "Real World" example of how or why to implement a Local Group Policy on a machine that is a member of a domain with Loopback Processing. It is technically accurate that you can replace User Setting coming from AD with Loopback Processing in a Local Policy...it's technically done everyday in many environments. That's one of the reasons it's there for.

FYI: YOu should also see similar scenarios with Loopback Processing when you take the 70-294.

sprkymrk

Keeping it simple:

If the loopback processing policy is set in the computer settings of a GPO (whether local, site, domain, or OU) it either ignores completely or merges any GPO normally aplied to the user logging in.

One thing I have never tested though is setting the Loopback Processing on a computer's local group policy to "enabled", and then setting it to "disabled" in a domain or OU policy also linked to that same computer. I would have to assume that Loopback Processing would be disabled in that case.

Loopback Processing is no different than any other computer configuration setting, it still gets applied in the order of Local, Site, Domain, OU. If Loopback Processing is applied at any level, as long as a higher level GPO does not over ride it, it will take effect. This is what famos was pointing out. I must admit though, I was almost the first to reply "No way!" to his post until I realized he wasn't saying that Loopback Processing at the local level over rides everything at the OU/domain level. This whole thread almost made my head hurt.

famosbrown

sprkymrk wrote:

Keeping it simple:

If the loopback processing policy is set in the computer settings of a GPO (whether local, site, domain, or OU) it either ignores completely or merges any GPO normally aplied to the user logging in.

One thing I have never tested though is setting the Loopback Processing on a computer's local group policy to "enabled", and then setting it to "disabled" in a domain or OU policy also linked to that same computer. I would have to assume that Loopback Processing would be disabled in that case.

Loopback Processing is no different than any other computer configuration setting, it still gets applied in the order of Local, Site, Domain, OU. If Loopback Processing is applied at any level, as long as a higher level GPO does not over ride it, it will take effect. This is what famos was pointing out. I must admit though, I was almost the first to reply "No way!" to his post until I realized he wasn't saying that Loopback Processing at the local level over rides everything at the OU/domain level. This whole thread almost made my head hurt.

Yeah, before I even replied, I was confused, so I decided to throw in a way to get the User settings to override AD GPO user settings. If the Local GPO Loopback processing is enabled, you wouldn't have to do anything to other GPO's...just make sure they are set to Not Defined.

A lot of environments do this type of thing so no matter who logs into a computer (Domain or Local user), they all get the same set requirements for that particular computer.

sprkymrk

Yes, I use loopback processing for conference room computers. All my users have a required 10 minute screensaver due to army regs, but in the conference rooms we don't want the screensavers kicking in while the command group is stuck on a power point slide for a while.

I would still suggest using a GPO to apply LoopBack processing to any computers that need it rather than local policy, for the simple reason that it's easier to administer and keep track of. It would be simple enough to create an OU called "LoopBack", "Kiosks", or in my case "Conference Rooms". Loopback processing only works if the computer is joined to an AD domain anyway, so it won't apply to stand alone or workgroup computers.

Apologies to the OP for getting off track. It was a worthwhile discussion at any rate.

famosbrown

Yep...that's another way to do it, but if you do not want to create a generic domain user account and rather create a local generic user account for public use, would the domain GPO's appply to that Local user? This is the reason I would use Local Policy.

sprkymrk

famosbrown wrote:

Yep...that's another way to do it, but if you do not want to create a generic domain user account and rather create a local generic user account for public use, would the domain GPO's appply to that Local user? This is the reason I would use Local Policy.

Good question, and my guess would be that "yes" it would. My reasoning (untried and untested) is because even though you are setting "user settings" in the GPO that you want to have applied, it's the "computer setting" that says to loop back to the user settings defined in THIS policy.

In effect, it's the LoopBack policy itself where you actually define what settings you want applied to the user. Sound right?

I can easily test this when I get back to the office to see for sure.

famosbrown

sprkymrk wrote:

famosbrown wrote:

Yep...that's another way to do it, but if you do not want to create a generic domain user account and rather create a local generic user account for public use, would the domain GPO's appply to that Local user? This is the reason I would use Local Policy.

Good question, and my guess would be that "yes" it would. My reasoning (untried and untested) is because even though you are setting "user settings" in the GPO that you want to have applied, it's the "computer setting" that says to loop back to the user settings defined in THIS policy.

In effect, it's the LoopBack policy itself where you actually define what settings you want applied to the user. Sound right?

I can easily test this when I get back to the office to see for sure.

Yeah...test that out with a local user, and let us know. Computer settings are applied at startup or shutdown only, so I would like to know if the User Settings will still be applied when a local user logs into the computer. When studying and doing labs with 70-294, it was recommended to use Local Policies for this type of thing...especially if you are talking about a few computers for Public access. With that, I've only used Local Policy, and have seen many environments doing the same to serve this purpose.

I left my laptop at work...otherwise I would VPN and test it out in my VM environemnt. I love this part of I.T. ! Test, discovery, and conclusion !!

sprkymrk

famosbrown wrote:

Yeah...test that out with a local user, and let us know. Computer settings are applied at startup or shutdown only, so I would like to know if the User Settings will still be applied when a local user logs into the computer.

What about Group Policy refresh every 90 minutes or so? That applies everything except security settings by default. (Note - the following link was a quick find and specifically for 2K, but to the best of my knowledge hasn't changed for 2K3):

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/gp/32.mspx?mfr=true

famosbrown wrote:

I love this part of I.T. ! Test, discovery, and conclusion !!

+1

famosbrown

sprkymrk wrote:

famosbrown wrote:

Yeah...test that out with a local user, and let us know. Computer settings are applied at startup or shutdown only, so I would like to know if the User Settings will still be applied when a local user logs into the computer.

What about Group Policy refresh every 90 minutes or so? That applies everything except security settings by default. (Note - the following link was a quick find and specifically for 2K, but to the best of my knowledge hasn't changed for 2K3):

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/gp/32.mspx?mfr=true

famosbrown wrote:

I love this part of I.T. ! Test, discovery, and conclusion !!

+1

Yeah...I know about about the refresh, but I would like to see if the settings will automatically change for the local user during the refresh...for example, Hiding the Run Command, no access to Control panel, no access to explore using UNC paths, a set background, etc. Will everything just change during that refresh? shouldn't the settings only apply when the user is logging on? I love this stuff . I have to work on a project for a new domain overseas, but if I get done in a decent time, I'm going to test this out. Even if the 90 minute refresh was true, I'm still allowing a Local User to have access that I don't want them to have when they login.

sprkymrk

It works.

I used a GPO with loopback set to replace, applied to an OU with a computer. Set options on the screensaver (5 total) and hid various tabs and menus. Set IE proxy.

Created a local user on the computer and the settings applied just fine.

Were there any specific issues you wanted to test/check?

but I would like to see if the settings will automatically change for the local user during the refresh...

You can always change the default behavior of the refresh if you find something not being applied. I use the settings under Computer>AdminTemplates>System>GroupPolicy to make sure the background refresh is set, and the various "policy processing" settings all are configured to the appropriate level.

famosbrown

sprkymrk wrote:

It works.

I used a GPO with loopback set to replace, applied to an OU with a computer. Set options on the screensaver (5 total) and hid various tabs and menus. Set IE proxy.

Created a local user on the computer and the settings applied just fine.

Were there any specific issues you wanted to test/check?

but I would like to see if the settings will automatically change for the local user during the refresh...

You can always change the default behavior of the refresh if you find something not being applied. I use the settings under Computer>AdminTemplates>System>GroupPolicy to make sure the background refresh is set, and the various "policy processing" settings all are configured to the appropriate level.

Sweet!!! You saved some testing for me! I'm sure this is probably the first and only resource on the net that will answer this question if someone else decides to google for it.

Great job Mark.

sprkymrk

famosbrown wrote:

Sweet!!! You saved some testing for me!

Of course every environment is different and we should always test in an isolated network before deploying. So I should qualify my answer as follows:


<disclaimer>
It worked for me in my environment as described. So we know it can work, but GP and AD can vary significantly from place to place so always test test test!
</disclaimer>

famosbrown wrote:

Great job Mark.

Great job to you and everyone in this thread. "Iron sharpens iron" as the saying goes.