I have been working with group policy recently and have been enjoying it. I wanted to share this knowledge with the rest of the world. I’m going to do that through a few scenarios. This first part is gathering information. More information you have, the more likely you will be successful at resolving the issue.
Scenario – User can’t hear conference call
The ticket came in as, “I can’t hear people on a conference call with XYZ company.” The help desk guy tried to figure it out. He updated the ticket with “It’s just broke.” Then he escalated the ticket to me. So, I called the person up and was blasted with an ear full of, “it ain’t working, and this be broke and that be broke, and I needed this call for a client, and and and…” The normal basically.
Who, What, Where, When, How
Here is the information I pulled. Who is the User? What computer is the user using? What is the real problem? Where is the Computer located? Where are the user and computer located in AD? When did this start happening? Finally, how can I recreate the issue?
Once I pulled that information, I discovered they were using a Website to communicate with an HR company via web conferencing. Hum… Anyways, The computer was in the standard laptop OU, and the user was inside the standard Recruiter’s OU. The problem was only noticed that week. I asked her to try another site and finally had her try google video conferencing. None of these technologies worked. I finally had her try a product She has used in the past that worked. This product was an in-house remote connect with the audio program. The in-house program worked. At this point, I knew the browser was ok. There was something else stopping it. I suspected Group Policy at this point.
Hum…
To confirm group policy was doing this to her, I ran the “Group Policy Results Wizard” in the group policy management console towards the bottom. Inside the wizard, I selected the computer she was on. Then I selected her. The wizard did its wizard magic and gave me a full list of everything that was applied to her, how long each step took, and which one won over the other. Sure enough, she had a browser policy attached to her. From the wizard, I was able to see the website she was trying to use was not listed. At this point, I had some work to do.
Make a change request with managements. If approved, move to the next step. If not, tell the user they are not allowed to use the conferenceing software on those sites.
Add the site to the group policy
then run gpupdate /force on her computer
Management did not approve the change. So, I called the user and informed them of the issue. They were not happy, but then I had the power of management behind me.
Deeper Dive
There are a few things in the Scenario to take note of.
Getting the right information from the user is key.
Scopes of group policies on a user and the OU they are in.
The group policy management tool has some cool troubleshooting tools.
Permissions from Management, AKA, cya.
Getting the right information from the user
Getting the right information is hard sometimes. Here is the conversation that went down between me and her.
Me: Which computer is this happening on?
Her: ALL OF THEM! (First Key that it’s group policy)
Me: let’s focus on one computer. Which computer was the first computer you noticed this issue?
Her: Gives me a computer name.
Once I had the computer name that it happened first. I pinged it to see if it was active or not. I also know that she has logged into the computer within the past few days as the ticket she put in was only a few days old.
AD information and Scopes
As I had a hint that this might be a group policy-related item from when she said, “It happens Everywhere” I made sure to note at the OU the computer was located in and the OU the user was located in. Then I started up group policy management and looked at her and her computer there. Her OU had the browser policy inherited from the top-level user OU. Then I used the tools inside group policy to confirm the issue.
Using built in tools to confirm
Group policy management console has a set of very useful tools that will help out to gather information. The first tool is the Group Policy Modeling tool. This tool will create a “what if” to the information you feed it. It doesn’t need access to the computer in question, just the domain. The second tool, the one I used is called Group Policy Results. This bad boy needs access to the computer. What it does is it reaches into the computer and pulls the group policy information. This one shows you what happened. It’s kind of like running gpresult /r on a computer, but on drugs. This tool confirmed the browser policy was attached.
CYA like a kid in a candy shop
Group policy has the power to change everything that is connected to it. A simple small change can have rippling effects for years to come. There is a real chance of tattooing your network as well. Tattooing is where a group policy change stays after the policy has been removed. So, best to CYA yourself. For those that don’t know CYA means to cover your assets. This is why I brought management into the picture. They get paid the big bucks and if something happens, I can point to the email I sent to the management. The manager said no, and thus the answer became no.
I hope this was helpful for you all. The one thing I want you to take away from this blog is CYA! You can be the best at your job, but if you make a change and management don’t agree, cya can save your tail.
As always, if you have questions, feel free to ask.
In this article, I will guide you through the process of deploying webroot via Group Policy. This is a fairly straightforward process with only a little editing of the MSI. I am assuming you know how to download the MSI from the webroot portal. The portal changes often, so, I will leave this part out. If you are ready, throw on your group policy pins, and let’s get started.
Super Orca
The first thing you will need is the Super Orca. You can download it here, link. Once you get super orca installed, we will be able to download and set up the webroot MSI.
Open Super Orca
Open the Webroot MSI.
Click the Property On the left (Red Block).
Click GUILIC (Green Block)
Enter the Key Number
Click File
Click Save As
Save as a different name. ALWAYS KEEP THE ORIGINAL!
Shared Folder
Now you have the MSI ready. You need to place it into a shared folder location. This location has to be accessible to every computer in the company as a minimum of read-only. Make sure the share is shared! I can’t tell you how many times I made this mistake. If it’s shared, good, make sure some of the clients can reach it.
Group Policy
Now we have the MSI ready to go. It’s time for the group policy. It’s a very simple computer policy. In my experience, a lot of IT managers don’t want AVs on servers. So, this tutorial will include a wmi filter. Let’s get to it.
Open Group Policy.
Create a new policy and name it Workstation Webroot Deployment
Enter: select * from win32_operatingsystem where producttype = 1
The numbers mean:
Workstation
Domain Controller
Server
Click Ok
Under the WMI Filter Select the WMI Object.
All that is left is linking the GPO. Now you can link it wherever you want. Most orgs have an OU just for workstations and one for servers just for this case. It doesn’t matter where you link it the WMI filter will ignore servers and only hit the workstations.
As always, if you have questions, feel free to ask. If you ever see anything that is wrong, feel free to reach out and correct me. Thank you for reading.
Recently a IT specialist left a client’s company, and they left some time bombs. One of them was blocking command prompt for the end users. Normally this is not a problem, but they set the policy to a bad scope. Even the admins couldn’t use the command prompt. It was not pretty. So, lets take a look at the policy in our own lab.
Block Command Prompt
The blocking command prompt is very simple but can be done wrong. To start create the policy, it’s located at User > Policies > Administrative Templates > System > Prevent access to command prompt. Set the policy to enable and select yes to block script processing.
Scoping
Since this is a user GPO the scope is very important. Scope is based on the location where you link the GPO. So, if you link the gpo at the top of the domain or site level, everything will get it unless, of course, a counter policy is linked at a lower level that is enforced the same way. Here is the scope applied list.
Local GPOs
Site-Linked GPOs
Domain-Linked GPOs
OU-linked GPOs
Child OU-linked GPOs
In this case, the user linked the scope at the top of the domain instead of the OUs that need to be applied to. The simple fix was to move the policy link to the sub OUs.
Recently I came across a client that had an amazing legal notice before you logged into a computer. I also noticed that it didn’t remember who last logged in. This gave a unique level of security and provided a good AUL at the same time. I wanted to guide you through the process. This is done with Group Policy, thus a domain structure is the best bet. The first part is to forget the last logged-in user.
Forgetting the Last logon user
The first step is to start Group Policy Management. Then Create a new group policy object. There are multiple ways to do this, pick your favorite. I named my policy, ForgetLastLogonUser.
Inside the windows Group policy, lets navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Then we will enable Interactive logon: don’t display last signed-in.
This setup will remove the last logged on user which will help users remember their username and increase security through obscurity.
Legal Notice
The next thing they did was setup a legal notice. This is also known as a banner. Lets create another policy like above. I’m going to name my policy, LogonBanner. Click edit on your logonbanner and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options and double click Interactive Logon: Message text for user attempt to log on. This is where you will define your login message.
Next do the same thing for Interactive Logon: Message title for users attempting to log on.
With both of those in place, this is what it finally looks like.
That’s pretty rad. I hope you all like this little tutorial.
Did you know you can add a comment to a group policy? Did you know you can report on that comment as well. Basically, if you put the purpose and any additional information like security groups, applied to and not to, and so on and so forth, you can document and report on the group policy using PowerShell. Let me show you how.
Commenting Group Policy
There are two ways you can comment group policy, the first is the GUI. The second is through PowerShell. First we will do a comment via the GUI.
The GUI Way
300start Group Policy Management Console
Select the policy object you wish to comment
Right click and click edit on this policy
In the navigation plane, right click the policy’s name and select properties
Click the Comment tab
Enter your comment
Apply and Ok.
The PowerShell Way
The command we are going to be using is the get-gpo command. This command allows you to grab the single GPO or all of the GPOs in the company.
Get-GPO -Name "Control Panel Access"
Results of Get-GPO
You can see the comment we added to the policy earlier as the description. Why Microsoft hasn’t changed the name on the tab, I will never know. For anyone who is familiar with PowerShell there is no Set-GPO commandlet native to PowerShell. So, it’s time to put our thinking caps on and figure out what we can do. I piped this command into get-member.
Get-GPO -Name "Control Panel Access" | Get-Member
Results of the get member
Look what we found. The Description property has a set feature to it. This means you can set the property using the get-gpo command.. Bingo! Lets do this!
(Get-GPO -Name "Control Panel Access").Description = "This policy blocks access for all members of the employees group, except for those inside the sg_control_panel_access group from accessing control panel. 04/25/2021"
Results from the above command.
I wanted to add today’s date into the description. This way whoever comes behind me sees when it was written. Now let’s see if the GUI updated accordingly as well.
The new information is inside the policy
It updated like we believed it would. This is because of the set feature inside the property. The command allowed us to set the property. Such a simple and yet lovely thing. Now, you can run a report asking for just the name and description to get much more information. If you do this with all of your policies, life gets a little easier.
Maybe, one day I will use a dynamic parameter and create a set-GPOdescriptoin command to set the description of any gpo you can select from. Hum…
Like always, if you have any questions feel free to ask.
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.
