Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 34
  • Last Modified:

Group Policy not blocking inheritance

I created a screen lockout policy for our domain.  I have an OU set up for our Internet cafe since I do not want the computers in the cafe to have the same settings as the computers used by staff (Inheritance is blocked for this OU in Group Policy Management).  The computers in the Internet cafe have the screen lockout policy applied to them even though inheritance is blocked and GPM does not show the screen lockout policy being inherited by the OU.  What am I missing here?  Thanks!
0
SAndrewsLGBT
Asked:
SAndrewsLGBT
  • 7
  • 5
  • 2
3 Solutions
 
Joseph MoodyBlogger and wearer of all hats.Commented:
First, is the policy being set under user configuration? If so, the users can still apply it even though you have block inheritance on for the computer OU.

You may want to look at enable loopback policy processing in replace mode for these machines. It provides a consistent user experience no matter where users are located.
0
 
SAndrewsLGBTAuthor Commented:
It is being applied under user configuration.  Do I apply the loopback policy processing on the local GP of the machines that are affected?  Thanks!
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
You can. It would be better to set it in a GPO linked to the comptuer's OU. See this guide on configuring loopback: https://deployhappiness.com/loopback-policy-how-a-computer-gets-a-transgender-operation/
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
SAndrewsLGBTAuthor Commented:
I created the policy to enable loopback processing for the OU that the cafe computers are part of (loopback processing enabled, replace).  I restarted the computers in the cafe and the screens still lock from the prior policy :-(
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
Run a gpresult on those machines and ensure that loopback is enabled and set to replace.
0
 
SAndrewsLGBTAuthor Commented:
Loopback is enabled and set to replace.  I even restarted the machines a 2nd time.
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
Do you have this screen lockout policy linked to the computer OU or any higher ou?
0
 
SAndrewsLGBTAuthor Commented:
The lockout policy applies to the domain.  When we decided to create a screen lockout policy for staff I created an OU for the cafe computers (my predecessor did not have any OUs set up) and set the OU to block inheritance.  When I checked the computers under the OU for the cafe I see the loopback processing object was inherited.
0
 
Joseph MoodyBlogger and wearer of all hats.Commented:
Do you have the GPO enforced (lock symbol next to the link)? If so, unenforce it.
0
 
SAndrewsLGBTAuthor Commented:
The GPO is not enforced.  I read that "enforced" overrides "block inheritance"  All of our GPOs are set to "link enabled" and none to "enforced"  This is very baffling.
0
 
Adam BrownSr Solutions ArchitectCommented:
Loopback policy processing will apply User settings on all computer objects in any OU the policy with that setting applies to, including child OUs.

Personally, I would recommend re-designing your OU structure so that the company systems and users are in one OU "branch" and the public cafe systems/users are in a different branch. One of the main goals of OU structure design is to ensure that Block Inheritance and Enforced GPO settings are never used, since they greatly complicate troubleshooting efforts.

That said, run rsop.msc on the Cafe systems to determine where the policy settings are coming from. There's a good chance that the lockout settings were applied using Local policy, which, in the absence of a Group Policy that modifies those settings, would apply. If it's not in Local policy, look directly at the registry on one of the computers with the lockout settings applied. All of the Group Policy settings are basically pointers to registry modifications, and with that in mind there is also a possibility that someone set the lockout policy directly through the registry (a really really dumb way to do it, but it's still possible).
0
 
SAndrewsLGBTAuthor Commented:
Not sure what was causing the issue but I did finally get it to stop.  We use one general login for the cafe computers and then customers use a program installed on the computer to access the computer.  I moved that general login user to the Users OU of the cafe's OU and the issue has stopped (since the cafe OU blocks inheritance of any other GPOs.
0
 
Adam BrownSr Solutions ArchitectCommented:
If the policy was linked to the domain and the User wasn't already in an OU with policy block enabled, it doesn't matter if Loopback was enabled on the policy. It would still apply to the user.
0
 
SAndrewsLGBTAuthor Commented:
Adam Brown - " if Loopback was enabled on the policy"  Am I adding Loopback to the current policy or creating a separate Loopback policy?  I created a separate Loopback policy for the cafe OU.  Are you saying I'm supposed to add Loopback to the screen lockout policy which means it has both user and computer configurations?
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 7
  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now