This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Accurate Token Bloat Report

Hi,

I see there is a Token Bloat report which is based upon the object being in 'X' number of groups. Would it be possible to have a report created that takes in to account the number of groups the object is in (Directly and indirectly) and also the type of groups they are in as these have different values. It would also need to take in to account if there is SID History tied to the object an the groups themselves. Another consideration is whether the account is also delegated for delegation as this impacts the Token size.

An MS engineer wrote a script which is pretty accurate, but we would ideally want that criteria reporting off of the Quest data already captured, but taking in to account the same considerations.

https://gallery.technet.microsoft.com/scriptcenter/Check-for-MaxTokenSize-520e51e5

Thanks,

Adam

Parents
  • Hello,

     

    After a little bit of work, I have an approximation of the actual token size.  The script you referenced makes use of some logic which decide what the max token size should be which was not done.  instead I sort descending the token size, so the accounts at the top are the most likely to  have token bloat.

     

    Now for the caveats: the PowerShell script uses the Token Groups property for each user.  ER does not collect that field, so instead I have to use the group collections.  This means that if an user/group is added as a member of a group from another domain, Those foreign groups will only be included in the calculation if ER has collected those Domains.  Through my testing, I have some users which return the same results as the PowerShell script and others which are wildly off due to collections which have not happened.

     

    Alternate TokenSize check.zip

Reply
  • Hello,

     

    After a little bit of work, I have an approximation of the actual token size.  The script you referenced makes use of some logic which decide what the max token size should be which was not done.  instead I sort descending the token size, so the accounts at the top are the most likely to  have token bloat.

     

    Now for the caveats: the PowerShell script uses the Token Groups property for each user.  ER does not collect that field, so instead I have to use the group collections.  This means that if an user/group is added as a member of a group from another domain, Those foreign groups will only be included in the calculation if ER has collected those Domains.  Through my testing, I have some users which return the same results as the PowerShell script and others which are wildly off due to collections which have not happened.

     

    Alternate TokenSize check.zip

Children
No Data