JeffParton
asked on
Help with Active Directory token size.
The kerberos SSPI package generated an output token of size %1 bytes, which was too large to fit in the token buffer of size %2 bytes, provided by process id %3.
The output SSPI token being too large is probably the result of the user %4 being a member of a large number of groups.
Increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControl Set\Contro l\Lsa\Kerb eros\Param eters\MaxT okenSize.
OK, I did this and it works, BUT my question is this: This started erroring at 11:00AM yesterday. NOTHING was changed for any people in any groups at all. So the SID token, so to speak, should not have changed for ANY users. Is there a way to find out exactly what changed at 11:00AM yesterday that would have caused the 12000 byte limit to the token size to be overmaxed causing this issue? I have changed the MaxTokenSize to 65535 and the users affected are now working. I had to change ALL servers that has some form of KDC authentication with this new parameter. Without ANY changes being made what could have just "magically shoved it over the limit"? I need to find this but no clue how to. Any ideas?
The output SSPI token being too large is probably the result of the user %4 being a member of a large number of groups.
Increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControl
OK, I did this and it works, BUT my question is this: This started erroring at 11:00AM yesterday. NOTHING was changed for any people in any groups at all. So the SID token, so to speak, should not have changed for ANY users. Is there a way to find out exactly what changed at 11:00AM yesterday that would have caused the 12000 byte limit to the token size to be overmaxed causing this issue? I have changed the MaxTokenSize to 65535 and the users affected are now working. I had to change ALL servers that has some form of KDC authentication with this new parameter. Without ANY changes being made what could have just "magically shoved it over the limit"? I need to find this but no clue how to. Any ideas?
Note The size of the user security token grows together with the number of groups to which the user belongs.
ASKER
NJComputerNetworks, I figured out what causes the security token to grow. In my question I noted that NO changes were made to any groups the users belong to in weeks, thus, no growth in security tokens was expected. Then it just "stopped" working and errored. I am trying to find out how to research what "straw broke the camels back" so to speak. I am a little concerned that some sort of of virus has gotten in that I can't trace or detect, or whatever else may have happened. "Something" made it start erroring, and all the things I can find point to group memberships, which HAS NOT changed. Only 3 people have the ability to edit/add/delete group memberships and none of us changed anything. I am curious if anyone knows of a way to find what specifically changed at 11:00 that initiated the error chain.
In other words, I know what the error is and "what" has happened, I am trying to find a way to find out what "specific addition" caused the security token to grow beyond the limit. Is there a way of backtracking to find "what change" in AD caused the change.
In other words, I know what the error is and "what" has happened, I am trying to find a way to find out what "specific addition" caused the security token to grow beyond the limit. Is there a way of backtracking to find "what change" in AD caused the change.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.