What does your local group membership look like?

๐——๐—ฒ๐—ณ๐—ฎ๐˜‚๐—น๐˜ โ†’ ๐—›๐—ฎ๐—ฟ๐—ฑ๐—ฒ๐—ป๐—ฒ๐—ฑ

Real configs. Real fixes. Windows & AD security.

๐—ช๐—ต๐—ฎ๐˜ ๐—ฑ๐—ผ๐—ฒ๐˜€ ๐˜†๐—ผ๐˜‚๐—ฟ ๐—น๐—ผ๐—ฐ๐—ฎ๐—น ๐—ด๐—ฟ๐—ผ๐˜‚๐—ฝ ๐—บ๐—ฒ๐—บ๐—ฏ๐—ฒ๐—ฟ๐˜€๐—ต๐—ถ๐—ฝ ๐—น๐—ผ๐—ผ๐—ธ ๐—น๐—ถ๐—ธ๐—ฒ?

During my security assessments, I unfortunately often see the โ€œleft sideโ€.

๐Ÿ”ธ Messy local group membership.

๐Ÿ”ธ No clear ownership.

๐Ÿ”ธ No defined state.

๐Ÿ”ธ No real control over who can access the device interactively or who is local admin on it.

And this is very typical.

Over time, ๐—ฐ๐—ผ๐—ป๐—ณ๐—ถ๐—ด๐˜‚๐—ฟ๐—ฎ๐˜๐—ถ๐—ผ๐—ป ๐—ฑ๐—ฟ๐—ถ๐—ณ๐˜๐˜€. Administrators, external providers, developers, project teams, support teamsโ€ฆ people keep adding members when they need access. Projects come and go. ๐—”๐—ฐ๐—ฐ๐—ฒ๐˜€๐˜€ ๐˜€๐˜๐—ฎ๐˜†๐˜€.

โš ๏ธ Unmanaged local group membership can easily create ๐˜‚๐—ป๐—ป๐—ฒ๐—ฐ๐—ฒ๐˜€๐˜€๐—ฎ๐—ฟ๐˜† ๐—ฎ๐˜๐˜๐—ฎ๐—ฐ๐—ธ ๐—ฝ๐—ฎ๐˜๐—ต๐˜€ across your environment.

๐—ฌ๐—ผ๐˜‚ ๐˜€๐—ต๐—ผ๐˜‚๐—น๐—ฑ ๐—ฐ๐—ผ๐—ป๐˜๐—ฟ๐—ผ๐—น ๐˜๐—ต๐—ถ๐˜€ ๐˜๐—ต๐—ฟ๐—ผ๐˜‚๐—ด๐—ต ๐˜๐˜„๐—ผ ๐˜๐—ต๐—ถ๐—ป๐—ด๐˜€:

1๏ธโƒฃ User Rights Assignment – who can log on locally, over RDP, as a service, etc.

2๏ธโƒฃ Local group membership – who is actually a local administrator or member of other sensitive local groups.

Both should be ๐˜€๐˜๐—ฟ๐—ถ๐—ฐ๐˜๐—น๐˜† ๐—ฑ๐—ฒ๐—ณ๐—ถ๐—ป๐—ฒ๐—ฑ ๐—ฎ๐—ป๐—ฑ ๐—ฐ๐—ผ๐—ป๐˜๐—ฟ๐—ผ๐—น๐—น๐—ฒ๐—ฑ. This is usually part of a proper Tiering Model implementation, where you define tiers, memberships, privileges, and access restrictions.

But letโ€™s focus only on local group membership here. The best way I usually implement this is through ๐—š๐—ฟ๐—ผ๐˜‚๐—ฝ ๐—ฃ๐—ผ๐—น๐—ถ๐—ฐ๐˜† ๐—ฃ๐—ฟ๐—ฒ๐—ณ๐—ฒ๐—ฟ๐—ฒ๐—ป๐—ฐ๐—ฒ๐˜€.

๐—›๐—ถ๐—ด๐—ต ๐—น๐—ฒ๐˜ƒ๐—ฒ๐—น ๐—ถ๐—ฑ๐—ฒ๐—ฎ:

1๏ธโƒฃ Higher OU / tier structure

โ–ช๏ธ Define the expected local Administrators group for that group of devices.

โ–ช๏ธ Here you remove all current members and groups, and then add only what should be there.

โ–ช๏ธ The built-in local Administrator account with RID 500 stays automatically.

2๏ธโƒฃ Lower OU / more specific structure

โ–ช๏ธ You can then add additional members where needed, but without clearing the whole group again.

โœ… This way, when GPO applies, it ๐—ฟ๐—ฒ๐—บ๐—ผ๐˜ƒ๐—ฒ๐˜€ ๐˜‚๐—ป๐˜„๐—ฎ๐—ป๐˜๐—ฒ๐—ฑ members and rebuilds the group into the expected state.

โžก๏ธ But be careful. Just because you can keep adding members lower in the structure does not mean you should. You still need to think about the ๐—ง๐—ถ๐—ฒ๐—ฟ๐—ถ๐—ป๐—ด ๐— ๐—ผ๐—ฑ๐—ฒ๐—น and avoid creating cross-tier attack paths.

This exact implementation is something I teach in my Building a Secure Active Directory ๐—ฐ๐—ผ๐˜‚๐—ฟ๐˜€๐—ฒ, where you ๐—ฏ๐˜‚๐—ถ๐—น๐—ฑ ๐—ฎ ๐—ง๐—ถ๐—ฒ๐—ฟ๐—ถ๐—ป๐—ด ๐— ๐—ผ๐—ฑ๐—ฒ๐—น ๐—ผ๐—ป ๐˜†๐—ผ๐˜‚๐—ฟ ๐—ผ๐˜„๐—ป and enforce control over local group membership.

Another option is ๐—ฅ๐—ฒ๐˜€๐˜๐—ฟ๐—ถ๐—ฐ๐˜๐—ฒ๐—ฑ ๐—š๐—ฟ๐—ผ๐˜‚๐—ฝ๐˜€, but in most real environments I find it too rigid and not flexible enough for this use case.

What do you use to keep local group memberships clean and controlled?