Onboarding a new client can take some time. Getting to know the client, their environment, and much more is very important. While talking with a client, the client needed to extend the cache on the mailbox so they could search past 12 months. Not a problem, just slip into the control panel, select mail, double click the update button, and off to the races we go. Simple as that right? Well, the problem, control panel said, nope. The control panel was disabled. Not my first time seeing this. Of course, I went through the start menu to get to the mailbox options. Later I needed to uninstall some security software to load our software. I went to the control panel, and it said nope. At this point, I was a little shocked. Who would block even domain admins from working with the control panel? This either was a registry hack or a group policy. My money was on the group policy.
The Problem
All users accessing control panel is prompted with the above prompt. This even applies to the domain admin accounts.
Steps of Troubleshooting
I started from the local computer as I had access to the local computer at the time. The first thing I did was run the gpresult /r command. This command will show you the applied group policies. Here I found a policy called “Control Panel Access”. Which I had to thank the admin who named it. Having good names for your group policies is very important.
Next, I remoted into the server listed in the command’s results “Group Policy was applied from”. I started up the Group policy and Found the policy. I checked the comment section for any documentation, none was found. But I did find this …
I was taken a little back at this setup. The policy (Green arrow) prohibits anyone that has this policy applied to them to be able to access the control panel. The GPO status (Purple arrow) shows that it is enabled. So it’s working. Our error message proved that. Here is the kicker. The security filtering was set to authenticated users. Basically, someone didn’t finish setting this up. Logically, you want to limit access to programs within the control panel. Then delegate access to those who need to be able to access those settings accordingly.
The next step was to send my findings to the client. We spoke for a while and It was finally decided that a group of people would have access, but everyone else, wouldn’t. This was admins, laptop users, and a few others.
The Real Problem
Let us talk about the real problem for a while. The real problem here is the authenticated users. This is similar to the everyone group in the active directory. If they have a user account that authenticates with AD, then the policy will apply because the “apply” flag is set. The second part of this is the policy was applied on the top level. This means the policy was applied to everyone. That’s an “Oh, crap” moment for any admin.
The authenticated user is very important and almost every group policy will have to use it. However, I can only count on a few finger cases where you will need to set the apply flag. What do I mean by that? Click on the delegation tab and you will see how the policy is delegated. How gets it and who doesn’t.
The best way to see how these settings are set on a user is to click the user in question (Authenticated users) and click advanced. From here it will look and feel like a file permissions with a few little differences.
Here you see the authenticated users have the read flag set. This means any user can read this policy. This allows the system to determine if and where the policy should be applied. If this is set to deny, then no one will be able to read and thus no one would be able to apply. Read is a basic requirement for most policies. However…
The apply is what is causing the issue here. If we uncheck this, then the policy would not apply to any users. This isn’t the fix we are looking for, but it’s a start. There are no other groups that have “apply” attached to this policy. So it’s time to make some.
The Resolution
The resolution is simple,
- we created a security group called SG_Control_Panel_Access and added our users into the group.
- We added the Employees group to the policy as a read/allow apply/allow.
- Then we added the sg_control_panel_access to the policy as a read/allow, apply/deny.
- Finally, we unchecked the apply/allow from the authenticated users.
- completed a gpupdate /force on the end user’s computer and gpresult /r.
So, what does this work? The Employees group is the group that stores all active employees. Most organizations have this group or a group like it. It normally sits in their templates or whatnots. We give employees the right to read and apply. This “allow” access will make sure the policy applies to everyone in that group.
The second part of this is the deny option to the “apply” for the sg_control_panel_access group. Deny will take precedence over allow every time, except for authenticated users. Thus, when the account reads the policy, it chooses not to apply it because the flag said to. Thus, the policy never applies. Thus, the user has access to the control panel. YAY!
The last part is to force an update to the group policy for that user/computer. gpupdate /force is magical as it speeds up the process. It tells the computer to go to group policy and get the information and update the policy. Sometimes this requires a logout, but not most times. The gpresult /r allows you to see if the policy did not apply.
At this point, I tested with the users. The problem was fixed. I wanted to take it one step farther and move the policy from the top level to the user OU. This way the policy wouldn’t be overwritten by an OU level policy. After I presented this idea, I was able to delink it from the domain level to the OU level. This means that only the users are going to be effected and none of my service accounts.
Documentation
The final step to any project is documentation. The best way to document group policy when you or the client doesn’t have a robust documentation system is to use the comment section in the group policy.
- Right-click on the policy itself
- Click edit.
- In the console tree, right-click the name
- click properties
- On the next box, click the comment tab
- Enter a useful comment.
The clearer details you can give, the better. In this case, we explained what it does, block access for the members of a group called employees except for those inside a control panel access security group from accessing the control panel.
Make sure you test, and document. If you don’t have a test environment, like in this case, then make one of your own and test. Test, and double test. Always document inside your document control, and in the policy itself. This way, if the document control dies, the policy has the comment. If you have any questions, feel free to ask away.