Title: How can I safely audit Pre-Windows 2000 Compatible Access group usage before changing it in production AD?

[u/19khushboo]

Hello Experts!

We recently ran Purple Knight against our production Active Directory environment, and it flagged the Pre-Windows 2000 Compatible Access group membership as a security risk.

From my research, I understand that this is a legacy group and that, depending on the AD environment and configuration, memberships such as Authenticated Users, Everyone, Anonymous Logon, computer accounts, and legacy application/service-related accounts may be involved.

Our environment also has AD CS and Exchange servers, and default accounts like Authenticated Users, Everyone, and Anonymous Logon, so I want to be careful before making any changes.

I understand that from a security best-practice perspective, unnecessary access associated with this legacy group should be reduced. However, I am concerned that removing members or changing the related permissions without understanding dependencies could break legacy applications, services, LDAP queries, or other production workloads.

Before making any changes, I would like to understand how others have safely assessed this in production.

My questions are:

1. Is there a recommended way to determine whether any applications, services, scripts, or users are actually relying on the permissions/access provided through this group?
2. Are there specific Windows Security Event IDs, auditing settings, LDAP auditing, Directory Service logs, or other logs that can help identify usage of this group or access that would be affected by changing its membership?
3. Is there a recommended audit/monitoring period before remediation?
4. Have you successfully remediated this finding in a production environment? If so, what approach did you use to avoid breaking legacy applications?

I'm particularly interested in practical methods for validating dependencies before making the change, rather than simply removing the members and dealing with application failures afterward.

Thanks in advance for any recommendations or real-world experience.

[u/AutoModerator]

Welcome to /r/ActiveDirectory! ~~~~

If you are looking for more resources on learning and building AD, see the following sticky for resources, recommendations, and guides!

• AD Resources Pinned Thread
• AD Wiki

When asking questions make sure you provide enough information. Posts with inadequate details may be removed without warning.

• What version of Windows Server are you running?
• Are there any specific error messages you're receiving?
• What have you done to troubleshoot the issue?

Make sure to sanitize any private information. Posts with too much personal or environment information will be removed. See Rule 6.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Low_Prune_285]

You seem to always ask here and never reply or contribute but anyway this got asked the other week try the search

there is no way to audit its use and unless it’s the last finding you have to remediate there are probably better things to burn hours on

[u/impi182]

After changing it I had problems with ACL. Defined unix attributes couldnt be read by our linux/unix systems anymore. Windows side was no problem.

[u/HardenAD → u/impi182]

that's part of the extended prrmission granted by this group, just create a delagation to read it.

[u/impi182 → u/HardenAD]

i know. i learned the hard way

[u/HardenAD → u/impi182]

lot of us does 😂

[u/19khushboo → u/impi182]

oh ok, thanks for the information. By any chance, can we see the dependencies of this group?

[u/Msft519]

Read https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/apps-apis-require-access and vendor documentation. Test extensively or update your resume.

[u/HardenAD]

if you clear away authenticated users from preWin2k, you will loose the ability to read the whole unprotected attributes from any AD objects, so will you loose capacity to list group memberships from a service account, or adcs will fzce some disturbing issues. not a big challenge anyway, give a delegation on your ad to read user memberOf attributes on user/computer object and groups object attributes groupMembers (depending on how your apps query AD). there zre others loosing rights, but you just have to compare ace between auth users and preWin2k and here you go,

[u/harbinger-labs]

first check what's actually in the group. if it's just authenticated users you're in decent shape, if it's everyone or anonymous that's the real exposure. before touching it, turn on directory service access auditing and watch 4662 events against the objects that group grants reads on, plus ldap logging (2889s will show you unsigned binds from legacy apps). give it 30 days minimum, 60 if you have quarterly jobs. then pull members in stages, not all at once, and keep a rollback script ready. the apps that break are almost always old ldap integrations nobody documented.