Powershell script to identify users with large token sizes

Question

_{Monday, July 9, 2012 5:14 PM}

Hello,

We had some users that are not able to log in to certain applications.  The affected users have been identified has having very large token sizes which are preventing logon to certain applications.  I would like to get an output of tokens sizes for all users which I can then sort from largest to smallest and start doing some cleanup.  I thought a PS script would probably be the best way to go about this.  Has anyone attempted something similar?

Thanks.

All replies (17)

_{Tuesday, July 10, 2012 3:30 PM ✅Answered | 1 vote}

Well gee Al, you're just all full of sunshine, aren't you?

A different approach would be to download TOKENSZ.EXE and throw it in your login script. Save the output to a share, 1 per user, wait however long it takes for most of your users to make new login, parse the output to produce a report.

http://www.microsoft.com/en-us/download/details.aspx?id=1448

C:\temp>tokensz.exe /compute_tokensize

Name: Kerberos Comment: Microsoft Kerberos V1.0
Current PackageInfo->MaxToken: 12000

Using user to user
QueryKeyInfo:
Signature algorithm =
Encrypt algorithm = RSADSI RC4-HMAC
KeySize = 128
Flags = 2083e
Signature Algorithm = -138
Encrypt Algorithm = 23
   Start:7/10/2012 5:24:33
  Expiry:7/10/2012 13:03:45
Current Time: 7/10/2012 5:24:33
MaxToken (complete context)  1780

_{Monday, July 9, 2012 5:20 PM}

What sort of token are you talking about?

Grant Ward, a.k.a. Bigteddy

_{Monday, July 9, 2012 5:26 PM}

These are the security tokens.  The issue is explained quite well here:

http://blogs.technet.com/b/exchange/archive/2005/12/28/416551.aspx

The article mentions how to fix the problem for an individual user once it comes up, but I'm trying to find these issues in advance before they become a problem. 

Here is a description of the tokens I am concerned with:

What is a user token?

A security token is the bundle of information that identifies the user and the security groups to which the user belongs. Each time the user tries to connect to a secured resource, the token must be presented to the resource so that it can determine whether access should be granted or denied. For detailed information about security tokens please refer to the Access Tokens Technical Reference in the Windows Server 2003 Technical Reference at:

_{Monday, July 9, 2012 5:40 PM}

I've had a read through that, and I don't see where Powershell can help.  Remember, Powershell is chiefly an automation tool, and almost anything you can do with Powershell can be done manually through a GUI.  There are exeptions.

The article you refer to mentions a number of ways to reduce the size of the security tokens, but none that I can see that could be automated.

Grant Ward, a.k.a. Bigteddy

_{Monday, July 9, 2012 5:42 PM}

I suspect he is referring to the "token" created when a user logs in that records all of the groups s/he is a member of, likely using the SIDs of the groups. We have experienced similar problems with IFMEMBER.EXE, which uses a fixed size buffer to read the token in, such that it fails if the token is larger. In our case it seemed that any user having more than about 100 security group memberships (including those resulting from group nesting) were mapping to the wrong shares because of this failure.

It coud be that the logon process of the applications in question also use IFMEMBER for some reason - perhaps to ensure that the user would have access before connecting them to the share on which the application resides. Either that, or these applications do something similar to what ifmember does.

Al Dunbar

_{Monday, July 9, 2012 5:45 PM}

I don't think you're understand my question. 

I'm not attempting to automate the reduction of token sizes for users.  I am simply trying to get a list of all users with high security token sizes and dump this list to a .xls file.  I'm sure this is possible from the GUI, but I'm trying to avoid manually checking 4000 users via AD.  I would be very surprised if powershell can't be used to produce this list. 

_{Monday, July 9, 2012 6:00 PM | 1 vote}

I don't think you're understand my question. 

I'm not attempting to automate the reduction of token sizes for users.  I am simply trying to get a list of all users with high security token sizes and dump this list to a .xls file.  I'm sure this is possible from the GUI, but I'm trying to avoid manually checking 4000 users via AD.  I would be very surprised if powershell can't be used to produce this list. 

The technet article you mentioned says this: "Various factors affect total token size and how many bytes are added per group. There is no simple mathematical formula for calculating token size based on the number of group memberships.". In fact, the actual size of the token is likely only known when the token is created, which only happens when the user logs on or authenticates.

If there were an exact formula, then, yes, powershell could produce an accurate list of those with large tokens. But until someone can determine what this exact formula is, all programmatic attempts will fail to provide what you are looking for, whether or not based on powershell.

You *might* be able to approximate an answer by creating a list of all users sorted by the number of security groups they belong to, including by group nesting. Then when you know user "A" has a problem, it seems likely that anyone with a higher number of groups also has the problem. Conversely if user "B" does not have the problem it seems likely that anyone with a lower number of groups is also OK.

Al Dunbar

_{Monday, July 9, 2012 6:37 PM}

There are other Microsoft documents that do post such a formula:

TokenSize = 1200 + 40d + 8s

This formula uses the following values:

• d: The number of domain local 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 security ID (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 domain.
• 1200: The estimated value for ticket overhead. This value can vary depending on factors such as DNS domain name length, client name, and other factors.

This is a rather complex issue, so forgive me for linking here http://support.microsoft.com/kb/327825/en-us

_{Tuesday, July 10, 2012 2:52 PM}

There are other Microsoft documents that do post such a formula:

TokenSize = 1200 + 40d + 8s

This formula uses the following values:

• d: The number of domain local 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 security ID (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 domain.
• 1200: The estimated value for ticket overhead. This value can vary depending on factors such as DNS domain name length, client name, and other factors.

This is a rather complex issue, so forgive me for linking here http://support.microsoft.com/kb/327825/en-us

That is definitely a formula, and quite a specific one. Unfortunately, as noted above, the 1200 constant is only an approximation. On top of that, the OP will also need to determine if the problem he is facing is precisely the kerberos authentication issue (for which some fixes/workarounds are suggested) or if it is something else - in which case it may be difficult to determine the token size threshold they should be looking for.

Al Dunbar

_{Thursday, July 12, 2012 2:13 PM}

Well gee Al, you're just all full of sunshine, aren't you?

A different approach would be to download TOKENSZ.EXE and throw it in your login script. Save the output to a share, 1 per user, wait however long it takes for most of your users to make new login, parse the output to produce a report.

http://www.microsoft.com/en-us/download/details.aspx?id=1448

C:\temp>tokensz.exe /compute_tokensize

Name: Kerberos Comment: Microsoft Kerberos V1.0
Current PackageInfo->MaxToken: 12000

Using user to user
QueryKeyInfo:
Signature algorithm =
Encrypt algorithm = RSADSI RC4-HMAC
KeySize = 128
Flags = 2083e
Signature Algorithm = -138
Encrypt Algorithm = 23
   Start:7/10/2012 5:24:33
  Expiry:7/10/2012 13:03:45
Current Time: 7/10/2012 5:24:33
MaxToken (complete context)  1780

This is an excellent suggestion!  Thanks.

_{Thursday, July 12, 2012 2:18 PM}

But it's not Powershell, is it?  I think that is what Al and I were trying to say.

Grant Ward, a.k.a. Bigteddy

_{Thursday, July 12, 2012 2:39 PM}

Well gee Al, you're just all full of sunshine, aren't you?

A different approach would be to download TOKENSZ.EXE and throw it in your login script. Save the output to a share, 1 per user, wait however long it takes for most of your users to make new login, parse the output to produce a report.

http://www.microsoft.com/en-us/download/details.aspx?id=1448

C:\temp>tokensz.exe /compute_tokensize

Name: Kerberos Comment: Microsoft Kerberos V1.0
Current PackageInfo->MaxToken: 12000

Using user to user
QueryKeyInfo:
Signature algorithm =
Encrypt algorithm = RSADSI RC4-HMAC
KeySize = 128
Flags = 2083e
Signature Algorithm = -138
Encrypt Algorithm = 23
   Start:7/10/2012 5:24:33
  Expiry:7/10/2012 13:03:45
Current Time: 7/10/2012 5:24:33
MaxToken (complete context)  1780

My comments resulted in you supplying the response that the user marked as answer, so I think my "sunshiney" job here is done - ;-)

Al Dunbar

_{Thursday, July 12, 2012 3:37 PM}

Al's objection seemed to be with the 1200 figure Microsoft gives in the formula for "estimated ticket overhead". That number can vary due to various things like the same of the domain. We had a good discussion and Dbutch is more informed.

_{Thursday, July 12, 2012 6:23 PM}

Al's objection seemed to be with the 1200 figure Microsoft gives in the formula for "estimated ticket overhead". That number can vary due to various things like the same of the domain. We had a good discussion and Dbutch is more informed.

... and has a workable solution he is happy with.

Craig is correct. My concern was primarily with the lack of exactitude in the formula. Had there been a formula that was completely accurate, then a powershell solution would have been feasible. Given that there isn't an exact formula, any powershell solution would have been only an approximation. That might have been good enough in this case, or it might not have.

tokensz.exe, by its very nuture,  would seem to yield an exact result, but needs to be run individually by every account in question.

The OP has obviously chosen accuracy over being able to run a script to collect estimated information. Sometimes the most appropriate solution isn't a script! ;-)

Al Dunbar

_{Tuesday, August 14, 2012 10:42 PM}

The link for the download doesn't work...is there another place where this is?

_{Wednesday, October 2, 2013 12:00 PM}

Hello all,

I know it's an old thread, but maybe it helps for other dataminers... :-)

http://www.msxfaq.de/tools/dump-ticketsize.1.6.ps1.txt

Stolen in Germany by msxfaq....

Best Regards

Florian

Schaue auf niemanden herab, es sei denn, du willst ihm aufhelfen...

_{Friday, June 9, 2017 2:00 PM}

This is a rather complex issue, so forgive me for linking here http://support.microsoft.com/kb/327825/en-us

Link is broken, now its 5 years old !

Here's the new link for the same KB Article: support.microsoft.com

And here's the Kerberos BLOG of its own: https://social.technet.microsoft.com/wiki/contents/articles/4209.kerberos-survival-guide.aspx