This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Hi everyone,
I'have a question, how can I protect the GPOs from enumeration from Tools like Bloodhound/PingCastle/PurpleKnight .... ?
how do you do, I'm working on a track to trap people who try to read GPOs that are not intended for them.
it can be interesting to be able to detect these random reads on important GPOs, and it will help a lot of companies in terms of security
Regards,
Hi,
It depends if you are trying to stop users from reading both machine and user based GPOs. For user based GPO it's a little more difficult as the user's account needs to be able to read the policies so they can be applied, you could make the allocation more specific rather than based the authenticated users group. For machine based policies it's a little easier, if you remove the authenticated users read and apply gpo permissions and apply the permissions to a specific group that only contains machine accounts. However, as machine group memberships are picked up on the next reboot, you just need to make sure you sequence the changes over a few days, so the machines still have access to read and apply the policies.
Changing the authenticated users to a user or machine specific group will limit who can read the policy settings.
Gary.
Just checking if there's any update or progress on this one?
Hi Gary,
Thanks you for reply, always precise answers, what I was looking for is not to denied users from reading some GPOs at the risk of breaking operation, but rather to trap those who try to read something that is not need it, surely for enumeration or attack. i thought of traking and no change the permissions.
I think that user dont need to read the GPOs in OU domain controller !!!
do you think what i think?
i have an idea on this and i guess it will work
Hi,
The option I suggested above is not intended to removing access (if done correctly), more about limiting access to only those that need it, e.g. on the default domain controller GPO, configuring permissions so only the domain controllers can access the specific policy, so you are preventing bad actors from see how you have configured your security.
This would be the new permissions which means only the domain controllers will be able to see and apply the policy.
If you just want to capture\report on who is accessing the GPO, then probably the best option is to set a SACL on the sysvol file structure, and then you will need to review the security event log.
This article has teh details on how to set the audit permissions on the file system - https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/apply-a-basic-audit-policy-on-a-file-or-folder
This post has the details on how to enable the audit settings and event ID details - https://social.technet.microsoft.com/wiki/contents/articles/15232.active-directory-services-audit-document-references.aspx
Let me know if you need any more info
Gary.
yes thank you for the feedback,
I think if you remove the authenticated user, the admins will not be able to read the GPOs because they are at the same time authenticated users and the refusal will prevail.
I thought of the same thing to audit and prevent on these GPOs it will be easier, auditing the sysvol folder is a heavy operation, I managed to do this, the result is satisfactory, I will improve my script and write a article above
ti have this result
https://www.linkedin.com/in/cyril-tiphineau-23a12166/
i will contact you to help me about this
Thanks,
By default the domain admins members will still be be able to manage/edit the policies. The authenticated user group only provides read and apply rights, rather than edit rights to the policies. If you delegate the admin/write rights to the policies then those delegated users will be able to edit/manage the policies.
Gary.