GPOs and Troubleshooting an Active Directory Infrastructure.
Just a word of warning ahead of time. This post transitions from talking about Security Baselines to GPOs, to troubleshooting a domain controller, then back to implementing a small GPO to add an additional layer of security to your endpoints.
A couple of weeks ago I posted on my twitter account what I should blog about next. The response was implementing Microsoft Security Baselines. I immediately went to the baseline website and downloaded the GPOs and documentation. I then realized that I will need more time to study over this and my Group Policy skills are lacking.
So, I studied over my AD book on the Group Policy chapter. Watched some YouTube videos and accessed some training on SkillPort. I then realized I was building out my Group Policies all wrong and applying them incorrectly. When I first started out, I would open Group Policy Management then right click on my domain and click on “Create a GPO in this domain and Link it here”. That is not a best practice. According to experts in the field, the only GPOS at this level should be the Default Domain Policy. The proper way to create a GPO is to create it in the Group Policy Objects Folder then link it in each OU. If you disagree with this, email me through my contact form or @ me on Twitter @johnwmintz.
In the process of doing all this, I noticed some instability in my domain infrastructure. I checked my replication with my domain controllers by using the command Repadmin /replsummary. I was getting errors 2148074274 and 8524. A few google searches and I found this issue is related to the source domain controller does not decrypt the service ticket that’s provided by the destination domain controller. Basically, the destination domain controller has an old password from Kerberos. The Microsoft Support page https://support.microsoft.com/en-us/help/2090913/active-directory-replication-error-2146893022-the-target-principal-nam provided me a step by step process to fix the issue. Now comes to the question of “Why did this happen in the first place?” My only idea is I am running all my VMs with VMware Player on a powerful Dell laptop. Once I get a server in place, I shouldn’t get this issue again hopefully.
I would also like to point out that I am running Server Core 2019 as my domain controllers. I am fairly impressed by the performance. I don’t see the issue above being related to Server Core.
I also built a small GPO that prevents executables from running in the APPDATA directories. This is a small security feature that provides an extra layer of defense against viruses, malware, and ransomware. You can find this under Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Software Restriction Policies. Open Additional Rules and right click on New Path Rule. In the path place %AppData%\*.exe then set Security Level as Disallowed. After running a group policy update on the target machine, I attempted to install Real Player. Then it prompted me for admin credentials. Even after providing admin credentials, I received the pop up below. The GPO done its job. I used the link https://www.brankovucinec.com/use-software-restriction-policies-to-block-viruses-and-malware/ to walk me through the process.
Hopefully I will have some time during the holidays to learn how to implement the Microsoft Security Baselines. From my initial research, Microsoft has stopped updating the Microsoft Security Compliance Manager and opted to offer the Microsoft Security Compliance Toolkit. So, this will entail more studying and labs for me. I hope everyone has a Merry Christmas and a Happy New Year.