Last October, I ran across a client with a broken radius. I want to go through the process I used to troubleshoot the issue. The goal of this to bring you a level of understanding of the troubleshooting processes. Not every process is the same for each It related item. Getting exposed to different steps from different people helps out.
Scenario
Here is the scenario. The client called and stated that no one is able to connect to the wifi. I looked at the device and saw that they were connecting via Radius. Radius allows you to use your username and password for the domain to login into the wifi. It’s one of the more secure ways to setup wifi. I had no documentation to fall back on. Thus, I knew nothing about the radius setup. However, I did know about the wifi controller. It was an Unifi controller.
Troubleshooting Radius – Discovery
Since we know that the devices are connecting to the wifi that is controlled through the Unifi controller, the first logical step is to go to the Unifi controller. I logged into the Controller and went to the settings button at the bottom of the left-hand side of the menu. From there I clicked on the WiFi menu option. I want to look at the wifi profile of the Corporate wifi. The one they are trying to connect to. Next, I scrolled down to the Security area.
Under the Security area, You will see the Radius Profile. Take note of this name. We will call our bob. Once you have that name, Click the profile on the left-hand side of the screen.
At this point, we have discovered the Radius Profile Name. Next, we need to dig into the Profile itself. More information the better when troubleshooting radius. Once you click on the Profile, scroll down to the Radius Section. From here, I found the name of the profile from before and clicked it.
Here we could see the Authentication servers’ IP addresses and ports. Now we know which server Radius is living on. From here, I go to the devices and find the Device they are trying to connect to. Thankfully, the device was named correctly. If it isn’t, then that’s a whole other ball game. I noted the IP address and mac address of the device. The device was active with no connections.
Troubleshooting Radius on the Server
I used RDP to access the IP address with success. I am thankful because sometimes the radius can be setup using compliance of some sort. Next, I connected to the Network Policy Server. After that, I connected to the Radius clients. Looking over the Friendly names, and IP addresses from the Unifi controller and the Radius Server, the problem was clear.
DHCP change occurred on the access points. This meant the NPS radius client IPs were wrong. To correct this, all I have to do is update the NPS Radius client’s IP addresses. However, I don’t want this to happen again. So, here are the steps I took.
Changed all the Access Points to Static instead of DHCP
Change the NPS Radius Client IP addresses to match.
Once I did this, The client was able to reconnect to their wifi using their windows domain credentials.
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.
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.Ok
