Default Domain Controller Policy settings changed?

[RyanD79]

If anyone can provide some insight into how to address this potential group policy situation, I would really appreciate it. I was using Policy Analyzer to compare the Default Domain Controller Policy for my lab environment and my production environment when I noticed that there are a lot of differences. Lab DC’S are running server 2019 and Production DC’s are 2022 but the production domain was originally created with 2000 DC’s.  Both forest functional levels are 2016. There are a lot of discrepancies in the User Rights Assignment section of the two GPOs and I don’t know if it’s due to production having been upgrade over the years or if people manual made changes to the GPO, or both.  Below are examples of the differences.

• There are a lot of unresolved SIDs in the production and none in the lab.“
  • Generate security audits”,” Logon as a service”, Adjust memory quotas for a process” and “Replace a process level token” all have a lot of unresolved SIDS listed
• Some settings in production are listed but blank while they are not listed at all in my lab
• “Log on as a batch job” lists IIS_USRS as having access while my lab shows BUILTIN\Administrator, BUILTIN\Back Operator, BUILTIN\Performance Log Users

I don’t like the idea of change the Default Domain Controller Policy, as it is not recommended, but I also don’t like the possibility of it being incorrect. So my question is what to do, if anything? My initial goal was to apply the security baseline GPO’s for domain controllers. I am now wondering if I need to clean the Default Domain Controller Policy first or just leave it as is and move on to the security baselines?  

Thanks

Ryan

[#2]

Read on here.

Some SIDs do not resolve into friendly names - Windows Server | Microsoft Docs

[#3]

Hello,

If you migrated from 2000 to 2022 over the years, you can expect two things:
1) Default Domain Controllers Policy (and Default Domain Policy) are slighty different between those OS - Microsoft hardened and updated those policies over time.

2) It is very likely someone has tampered with those policies, directly modifying them instead of pushing those changes to a seperate policy. You may also inherite from settings applied by legacy configuration on domain controllers (by example, IIS_USRS rights may indicate someone installed IIS role on domain controllers in the past). Please note some changes may be justified, like permissions added for on-premises Exchange infrastructure.

If possible, current DDCP should match a DDCP extracted from a brand new 2022 domain lab, and I strongly recommend to fix the first one before implementing security baseline. Of course you must analyze and test such changes before implementing them.
Once done, you can start testing and implementing Security Baseline policy settings. Of course, be sure to apply through a separate GPO.

[#4]

Thanks for the feedback. I believe both responses have help lead me to my answer.  If anyone read this in the future hopefully the information below will help them if they encounter a similar situation.

Capability SID’s were a new one for me as I’d never heard of them before. Researching them lead me to the page below that stated, “All Capability SIDs are prefixed by S-1-15-3”. This was not the case as my SIDs began with S-1-5-82 or S-1-5-80. I should have listed the SIDs in my original post for more clarity.

Security identifiers | Microsoft Docs

Below is the list of SIDs that were show in my default domain controller policy and the services/application pools that they are associate with.

S-1-5-82-271721585-897601226-2024613209-625570482-296978595 - .NETv4.5

S-1-5-82-3876422241-1344743610-1729199087-774402673-2621913236  - .Netv4.5 Classic

S-1-5-82-3006700770-424185619-1745488364-794895919-4004696415 – APS.NET (IIS APPOOL\DefaultAppPool)

S-1-5-80-1321940109-3370001082-3650459431-215109509-2472514016 - ADFS

S-1-5-80-2246541699-21809830-3603976364-117610243-975697593 – ADFS

After doing more research, I believe that at different points in time someone(s) install ADCS and ADFS on domain controllers. I could confirm the ADCS install since while that system has been demoted it has not decommissioned yet.  I was able to login to that system and see that ADCS was still installed. ADCS explains the SIDs associated with .net since IIS is also installed along with ADCS. Also, I could see the .Netv4.5, .Netv4.5 Classic and DefaultAppPool were all install on the former domain controller. This also explains why ISS_USRS was listed in the policy

 In regards to ADFS, another admin told me he installed ADFS on a DC once. Since then ADFS has been moved to dedicate servers.

We do have Exchange in our environment (production and lab) and while that was listed in the Default Domain Controller Policy it was not of a concern. Thanks for the feedback. It was much appreciated.