Group Scope?

  • Last Post 15 September 2017
a-ko posted this 12 September 2017

Hey all,   Was wondering if anyone here feels that group scope matters anymore? It seems to be a hot topic of discussion among the AD folks in my team. We have folks that basically insist on beginning to use universal scope groups for everything (we have a multi-domain forest) which allows us to use the groups anywhere and have members added from anywhere.   The argument to be made for this setup is that replication size isn’t really that important anymore, and neither is global catalog sizing. After all, many of us now have gig links between offices, and tons of ram available for domain controllers. (Things like query size and indexed attributes have a greater impact on performance it seems).   So, what’s everyone’s take? Can someone make a data driven argument as to why not to go this route and we should stick to the tried-and-true Domain Local & Global Groups model?   -Mike C

Order By: Standard | Newest | Votes
SmitaCarneiro posted this 12 September 2017

We are currently migrating between domains, and have an issue with token bloat for some users. And Domain Local groups increase the size of an users token, more than Global or Universal. So if the token size

matters to you, try to use groups other than DL.


Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy


ITaP logo clipping path2



Biju_Babu posted this 15 September 2017

Pretty much in a similar boat, especially if you have third-party self-serviceable access provisioning tools its bit difficult clarify the scope concept to end users in a request form. In order to simplify things  I kinda worded it like

“ groups used with in the region vs used across the region”, DL and Universal respectively.  May be I should simply settle with Universal alone..


I did this very recently though, may be too early to comment regarding the replication & GC size overhead.

I found this formula for token size calculation from my notes. It’s an old article, I don’t think there is much changed though.

How to calculate token size

Following formula to determine whether it is necessary to modify the MaxTokenSize value or not

TokenSize = [12 X number of user rights] + [token overhead] + [40 X number of group memberships] + 8s

This formula uses the following values:


 d: The number of domain logical groups a user is a member of plus the number of universal groups outside the user’s account

domain plus the number of groups represented in SID history.


 s: The number of security global groups that a user is a member of plus the number of universal groups in a user’s account



 User rights include rights such as “Log on locally” or “Access this Computer from the network”. The only user rights that

are added to an access token are those user rights that are configured on the server that hosts a secured resource. Most of the users are likely to have only two or three user rights on the Exchange server. Administrators may have dozens of user rights. Each

user right requires 12 bytes to store it in the token.


 Token overhead includes multiple fields such as the token source, expiration time, and impersonation information. For example,

a typical domain user has no special access or restrictions; token overhead is likely to be between 400 and 500 bytes.


 Estimated value for ticket overhead can vary depending on factors such as DNS domain name length, client name and other factors.


 Each group membership adds the group SID to the token together with an additional 16 bytes for associated attributes and

information. The maximum possible size for SID is 68 bytes. Therefore, each security group to which a user belongs typically adds 44 bytes to the user’s token size.

In scenarios in which delegation is used (for example, when users authentication to a domain controller), Microsoft recommends to double the token size.

Default token size is 12000.


Hope it helps.






barkills posted this 15 September 2017

We have a group management system external to Active Directory based on the open-source Grouper (

99.84% of all groups in our AD are created and managed via that external system (121,629 of 121,822 total AD groups). The connector/agent from that external group management system is event message bus based, and we typically see latency on the order of seconds

for any given change. We sync groups from this system to a variety of technology ecosystems that don’t play well with each other, including Google Apps, some shared Unix clusters, a LMS system, and others.


When designing the connector/agent for AD, we struggled with the AD group type issue. Initially, we decided to use the universal group type for all groups, because it was the simplest approach that ensured broad

usefulness. At that time, our AD was only usable across trusts (there were no computers joined to it), which meant only global or universal were useful. Our plan was to revisit this and later add support in our group management system for the other AD group

types. When we sat down to revisit & determine a design things were a little clearer:

-use of the AD domain had expanded to delegated OUs with computers

-there was no real issue with token sizes

-we realized that trying to explain the complexity of AD group types in a user interface was a non-starter


So we threw out our plans to adopt AD group types.


We have one known problem. We delegate group policy creator permissions to delegated OUs. The group which you must use to do that is Global (Group Policy Creator Owners) and being a built-in AD group, you can’t

change that. A Universal group can not be nested within a Global group. So when we create a new delegated OU group policy admins group, we manually change it to a global so we can then nest it within that group.


There’s a useful picture I created which is published at that I regularly reference whenever I deal with AD group types.


We did a pretty extensive analysis of AD token bloat in our AD back in 2011. An analysis paper is published at That paper includes a lot of conceptual background info and links to Microsoft source material. That background

info is very important because otherwise your calculations will miss the mark. It includes a link to the source ( for the formula Biju mentioned. We have not prioritized

completing the effectiveMemberships code mentioned in that paper, mostly because token bloat has been a non-issue compared to many other priorities. Finally, when doing this analysis we realized that token bloat represents a way anyone with group management

permissions in your organization could perform a denial of service on a given AD computer or user, and some computers or users are more critical (e.g. domain controllers). It’s worth noting that token bloat is not limited to AD. And that is one of many reasons

I really appreciated this:

Too bad something similar isn’t available for AD or more broadly for any AAD group.





SmitaCarneiro posted this 15 September 2017


The above on expiring groups is really interesting. It would be really useful at times when some folks are trigger happy with adding people to groups. How do you manage in places where the manager of the group

has left? Is there a backup owner field? And what happens in the case of nested groups? ( I don’t know if nesting is an option in O365).



Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy


ITaP logo clipping path2