Active Directory groups and local builtin groups: any best practice out there?

Question

We are running an Active Directory consisting of several different Windows machines (Vista, Windows 7, Windows 10, 2008 R2, 2012 R2, ...). I have to come up with a concept that allows for granular management of local permissions. Currently too many people got full rights on the machines.

I am planing to do the following:

1. Administrators (local group on ServerA) <==isMemberOf()== ServerA_Administrators
2. Backup Operators (local group on ServerA) <==isMemberOf()== ServerA_Backup Operators
3. etc...

Then I would do the same for ServerB, and so on. Later then I would aggregate those AD groups into a bigger ones like this:

1. Server_Administrators (members: ServerA_Administrators, ServerB_Administrators, ...)
2. Server_Backup Operators (members: ServerA_Backup Operators, ServerB_Backup Operators, ...)
3. etc.

That would allow me to control AD-side-wise, which user has local admin-rights. I could give users god-rights on all machines at once and others only one several machines (or only one).

The downside is that i would blow up the AD database, as many new groups are necessary.

Unfortunately I coudn't find any document from Microsoft describing the best practice in the respect of handling local builtin groups in an AD environment.

What would be the best way to achive my goal?

Answer 1

The number of groups itself is not the problem, it's finally scriptable - the number of group memberships is!(for example due to the kerberos max token size).
I prefer the following (Example for local Administrator Members)

Site A
Host A1: HostA1-Admin, SiteA Admin
Host A2: HostA2-Admin, SiteA Admin

Site B
Host B1: HostB1-Admin, SiteB Admin
Host B2: HostB2-Admin, SiteB Admin

So you can assign either single host or site related administration to your colleagues. Always try to reduce group membership. Cascading groups does not reduce this (see whoami /groups). If you have a forest, this differs a little but the problem stays the same.
Depending of your domain size either use scripts or gpos to add those groups to your local admins.
In addition see the group concepts in active directory (Domain local/Global/Universal), which is important for forest but for local domains as well since it impacts global catalog (it is the search index for your ad and used by many MS Services). Microsoft uses for local and global groups the terminology resource and user(?) groups as well, which already hints to the intended usage.

Answer 2

Be careful with the number of groups of which the user is! This number affects the size of the Kerberos ticket. After reaching a certain limit - the user can not log in. This is very important in large domains.

I recommend creating a group is not "per server", but "per role" of user ( accountant, operator, manager, administrator). And these groups, if necessary, include a local server group. Then it minimizes the number of domain groups to which the user belongs.