This is a discussion on “Scars” from group management days of yore within the Operating systems forums, part of the Tutorials category; Unfortunately, groups have a tarnished past that has left scars on many IT professionals from their experiences in Windows administration. ...
Unfortunately, groups have a tarnished past that has left scars on many IT professionals from their experiences in Windows administration. Back in the days of Windows NT 4.0 and earlier, groups had very limited nesting: Global groups could nest into local groups. That was it.
The best practice was to nest users in global groups and global groups into local groups, and then assign permissions to a local group.
The problem was that local groups existed only in the Security Accounts Manager (SAM) database of the server or workstation, not in the domain. So if your budget was distributed across four servers, you’d need four separate sets of local groups, one per server, if you followed the best practice. This best practice was quite painful in larger, complex organizations, many of which resorted to making all groups global groups. Because these groups couldn’t nest inside of each other, this approach provided for no hierarchy whatsoever, so there was no opportunity to represent business logic in a group model. Moreover, there was a significant limitation to the number of accounts that could be supported in a single domain. So it all broke down rapidly.
All of this changed with the introduction of Active Directory. As soon as a domain was at the Windows 2000 domain functional level or higher, a new scope of group (domain local) was available throughout the domain, and nesting global groups into global groups, or domain local groups into domain local groups, became possible. Universal groups are also available for nesting. Computers can now be added easily to groups, and group scopes and types can be converted. Finally, there is no practical limit to the number of objects that can be supported in an Active Directory domain. So life is much better now.
However, many IT professionals carry scars that become clearly visible when you start talking about group management. Either they believe that they already know all there is to know about groups, or they recoil in pain thinking, incorrectly, of how difficult group management must still be. It can take a lot of work to get past those scars.
If this sounds funny to you, consider yourself lucky! we’ve worked with many clients where, as we charted out a role-based management strategy, we actually had to ban the words “global group” and “domain local group” from the discussion! Administrators often want to jump right into the technology, the how, skipping the more important questions of why, what, when, where, and who. And invariably they end up introducing what they feel are salient technical concerns without first envisioning the future, recognizing the pain points that can be solved, and understanding that it’s not a one-page cheat sheet that will get them to the solution. Role based management—its analysis, design, implementation, support, and troubleshooting— takes work. But it pays off!