A while back, a client called and told me he made a few new group policies, and they were not working as expected. He stated some policies applied to the wrong users, while another didn't apply at all to any users. He stated he set the security group correctly. When I hear, "The policy didn't apply, or the policy is applying to the wrong person, I immediately think, delegation. Let's look at the two policies and what broke them.
Scenario - Restricted Google Chrome Policy applying to everyone.
This client had special needs to restrict google chrome. This included items like the auto-fill feature to be turned off, prohibiting Chrome extensions, and more. This was user policy. He only wanted it to Restrict to the techs computers, and not the management nor the IT department.
Who, What, Where, When, How
Who: This was effecting all the users at once.
What: A chrome policy that restricted users in google chrome.
Where: Everywhere
When: After the client applied the google chrome policy.
How: Through Group Policy.
It was clear, group policy was the issue. So, I took a gander at the delegation of the policy he called "Restricted Chrome Policy". The policy
Immediately, I saw that the tech group was not in the policy. In fact, this was the standard policy setup. However, one thing I have learned over the years, never to assume. So, I clicked the authenticated users and clicked the advanced button at the bottom of the delegation screen.
Showing Read is checked
Showing Apply is checked
In this case, I was right in my assumption. The authenticated user are every user on the domain. This is a large group and it's required for any group policy to work. The thing about it though, if the "Apply group policy" is checked, it applies the group policy to everyone. (Unless another policy closing to the ad object applies or enabled that overwrites the policy in question. )
This is what I did. I unchecked the "Apply Group Policy" check box. Created a security group called SG_Policy_Chrome_Tech and added all the techs inside that group. Then I add that group to the delegation. I made sure the read was checked and apply group policy was checked. Then on an end user's computer, I ran the gpupdate /force and the policy was applied correctly.
Scenario - Group Policy wasn't applied at all.
The second policy was harder to track down as it was a password alert policy. (Something I will cover later). The policy was to prompt a user within 14 days that their password is going to expire. It is done with a simple logon script. Very simple script, very simple policy. They called it "Password Prompt". The client discovered it wasn't being applied when he completed a gpresult /r on an end-user and didn't see it. It turns out that it was only meant for users and not service accounts.
Who, What, Where, When, How
Who: Users
What: Password Prompt is not applying
Where: Main OU level
When: Always
How: Hum...
By default, group policy management opens the policy where you can see the scope. I noticed right there something was missing. The client had set the user's group "employees" but I didn't see authenticated users. I went to the delegation tab, and I was right. There was no authenticated users group. I went through and added the authenticated users group, and made sure the "Apply this policy" wasn't checked, and read was checked.
The reason we do this is we want everyone to read the policy, but not apply it. How can you apply something you know nothing about? The same concept is applied here. The computer account can't read the policy if it doesn't know it exists. The authenticated user allows that reading. Once set, and a good old gpupdate /force was applied. The password policy showed applied.
Another way you can go about doing this is by adding the domain computers group. As it is the computer that will need to read the policy. This is thanks to the June 14 2016 security update.
The takeaway
Delegation is important. The Authenticated user's group is required in all group policies at a minimum of read. If you set the authenticated user's group to read-only, you use a security group with apply in order to apply a policy. The scope screen only shows you what is being applied, and thus, you may not even notice the authenticated users.
I hope this has been helpful for you. As always, if you have questions reach out to me.
Any IT professional will tell you, technology changes almost daily. Some things seem like they will never change then bam, it changes. For example the dependency on IE. In the 90s and most of the 20s it was IE. Firefox and Chrome started back then but didn't really gain traction. Now here it is 2021, Google search no longer supports IE. Microsoft no longer supports IE. IE is a bad word in the security world. So it's time to move away from IE. Most companies have done just that. Thousands of security-minded websites no longer develop for IE and purposely broken their sites on IE. The immortal IE was a problem this week.
Scenario - Always IE
A user called in and stated "Every time I go to ADP I get a message saying 'Your browser isn't supported.'" The browser was IE. ADP was a URL link on the desktop. URL links go to the default browser. The user stated that they changed the default browser to Google Chrome more than once, but it changes back after they restart the computer.
Who, What, Where, When, How
Who: The user was a standard user and located in the User OU in AD.
What: URL link is opening IE instead of google chrome.
Where: End user's laptop.
When: Every time they reboot.
How: When they double click a url icon.
With this info gathered, I started troubleshooting. I changed the default browser to Google chrome. The user stated after a reboot it changes back. I rebooted the machine to see this behavior. Sure enough, the default app changed from Google Chrome to IE. The most common thing that changes the default apps around is Group Policy. I ran gpresult /r on the computer and saw a default app policy.
Hum...
I logged into the server and loaded the group policy. Sure enough, there was a default app policy. This policy lived at the top level of the domain as well. Default app policy lives under Computer > Policies > Administrative Templates > Windows Components > File Explorer > Default Associations Configuration File. They use an XML file on a share that can be read by everyone in the company. I looked into this file and saw .htm, .HTML, HTTP, and https were set to internet explorer.
At this point, I knew this was going to be a change request. I informed the client that this is a change request. Then I contacted the client's leadership and acquired permission from the leadership via email. They responded with, YES PLEASE! This is my CYA that I needed. My assets were covered. Time to kick it into high gear.
Inside the default app XML file, I changed the .htm, .HTML, HTTP, and HTTPS progId to ChromeHTML and the ApplicationName to Google Chrome. This is what it looked like.
I asked the user to reboot their computer and test if the URLs opened in google chrome. The user reported that it did. I called few other users in the org and tested with them. Normally I would create a new OU and test with a test box, but this client did not have a test box. So, why not test in production! Please don't test in production unless you have to.
In the end, the problem was a Default App Policy. Fixing that fixed more than just this single user's issue. The leadership was happy with the change and they enjoyed using their drag and drop URL icons.
As always, if you have questions, feel free to ask.
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.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
