[gptalk] Re: Domain User account and GP processing

  • From: "Cruz, Jerome L" <jerome.l.cruz@xxxxxxxxxx>
  • To: "gptalk@xxxxxxxxxxxxx" <gptalk@xxxxxxxxxxxxx>
  • Date: Thu, 5 Jun 2008 17:11:39 -0500

In short... there is no "generally accepted" maximum number of groups. The 
maximums are determined by the MaxTokenSize entry and that value can be changed 
based upon your business requirements. Personally, I am a member of 264 groups 
in my forest and have no authentication or logon performance issues (we've set 
our MaxTokenSize to its maximum value).

Jerry Cruz

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Cruz, Jerome L
Sent: Thursday, June 05, 2008 2:57 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Domain User account and GP processing

Hi John, you asked

  << Is there a maximum number of groups it is generally accepted a user should 
(rather than could)
        be part of that would not impact login performance?">>

That depends upon several factors. What's your domain's defined MaxTokenSize 
entry in the registry? How many Local groups is the average user account in? 
How many Domain Global / Universal groups? Any cross-domain groups? Are the 
accounts Trusted for Delegation?

Microsoft has a good KB article that discusses this (and hotfix available if 

New resolution for problems with Kerberos authentication when users belong to 
many groups

They also have a KB article that shows you how to use a GPO to set this value 
(if necessary) on your devices.

How to use Group Policy to add the MaxTokenSize registry entry to multiple 
computers on a domain controller that is running Windows Server 2003 or that is 
running Windows 2000

All that said, while it does take "longer" to authenticate certain things, 
especially for cross-domain memberships, it's also not something the average 
user should ever notice. It certainly does not typically add 10-20 extra 
seconds to any logon that I've ever seen. Let's say that an End User's token is 
50 KB in size (that's huge). That's also not something that should take more 
than a few milliseconds to download on a 10 Megabit network connection. Even if 
the user is accessing things remotely (and mind you, they'd typically be using 
locally cached credentials..., but let's say for example that they use an 
'ancient' 56 Kilobit speed modem at the User Logon Screen to connect first), 
then it'd only take about 8 seconds to get their entire token (even that 
assumes no line compression...and even that is unlikely).

If your folks are experiencing slow logons, there's way more to look at. I be 
asking things like: Do they utilize Roaming Profiles? Are any poorly performing 
services staring up right away that are eating the CPU for breakfast? Are you 
deploying many applications at logon time? If so, is this slowing down the 
entire network throughput for everyone?

Also, instead of "security groups", perhaps what sounds like your internal 
"custom application" could instead utilize "Distribution Lists". My 
understanding is that this would at least "lighten" the load and reduce the 
chance of Token Bloat. Here is something I just ran across from Microsoft 
(published Feb 2008) that discusses a similar approach (for another purpose, 
but similar in goal to keep user's token's size within reason).

Provisioning Objects Based on Group Membership

"As a matter of best practice to avoid the well known "Token Bloat" problem, 
MCS decided to use AD Distribution Lists for the groups leveraged by this 

Good Luck....

Jerry Cruz | Group Policies Product Manager | Boeing IT

-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of John Bateman
Sent: Thursday, June 05, 2008 1:59 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Domain User account and GP processing


Say we have a software distribution product which uses AD for policy
resolution. So for example, if we wanted a particular machine to have a
certain piece of software, we simply add it to an AD group which has the
software policy assigned to it and away it goes. We can also do this with
users (so a user can be put into an AD group), however it is a little
different. In this instance we have the idea of mandatory and optional
software. If we assign a policy to an AD group and give it the attribute of
optional, the user can install if they wish but it will not be forced. As
all users are part of the Domain Users group if say a piece of software was
packaged that all staff could install, but would be optional, then an AD
group would be created and Domain Users group would be added to the group.
This has led to quite a number of AD groups and as users are all part of
Domain Users then they also belong to these groups (at least 40). Computer
accounts are not part of nearly as many.

Please note: we do not use GP software distribution, we have a product we

Now my questions:

1. Assuming that no AD groups are changed for a day nor are any group policy
objects. If a user logs in, policy processing does not occur as it does not
detect any changes in GPO or group membership (or WMI filters). If we then
add Domain Users to a new AD group, processing would then occur on the next
login correct?

2. Is this a common scenario with software distribution products that use AD
to resolve policy?

3. Is there a maximum number of groups it is generally accepted a user
should (rather than could) be part of that would not impact login


You can unsubscribe from gptalk by sending email to 
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by 
logging into the freelists.org Web interface. Archives for the list are 
available at http://www.freelists.org/archives/gptalk/

Other related posts: