This is a simple logon test using the LogonUser API to test if a set of credentials are valid. If the logon is successful then the account's groups and privileges are displayed. There are number of options to select the type of logon to be performed, this can be used to confirm that user rights have been configured correctly on the local computer.
This option shows an indicative number of SIDs that will be added to a user's or computer's access token when they authenticate against the the domain. The Base DN defined the start point for the search, if left blank, the entire directory is searched. There are also a number of options that can be used to limit the items that are returned, by default only the the top 100 entries are displayed, however this can be changed.
Limiting the search to only Groups is a method to determine if there are any groups which have a high number of nested groups, which could impact the size of a user's access token if users are added to the group.
The size column is for reference only, this is the size of the data returned by TokenGroups attribute for the corresponding object, while it can be used as an indication of the resulting token size it is not exact, see the Microsoft article for the formula for calculating the token size.
The right click context menu provides a number of options to investigate the token size further, the Display SID Inheritance option allows you to drill down into the access token to see which items are causing the token bloat.
Background: Windows use a buffer to hold the user's access access token, the size of this buffer varies in size between different versions of Windows, see: http://support.microsoft.com/kb/327825. While you can increase the size of the token supported by the OS, there is no way to increase the maximum size supported by IIS prior to version 6. User who is a member of 100+ groups thy may experience intermittent access to resources, over 300 they will have IIS\Sharepoint issues, over 1015 and the user will not be able to logon. The use of SID History for migration or consolidations only makes the token size issue worse. This is quite a good white paper on the issue http://www.giac.org/paper/gsec/5111/kerberos-access-token-limitations/104962