whoami - User, Group and Privileges in Windows Access Tokens

whoami.exe is a Windows command-line utility designed to help you find out who is currently logged on to a Windows user machine, as well as what groups and privileges are contained in the user-access token of the currently logged-on user.

whoami

How to Use WhoAmiI to View The Currently Logged-on User's Windows Access Token

The following is usage information of whoami -

C:\Users\STaylor>whoami /?

WhoAmI has three ways of working:

Syntax 1:
    WHOAMI [/UPN | /FQDN | /LOGONID]

Syntax 2:
    WHOAMI { [/USER] [/GROUPS] [/PRIV] } [/FO format] [/NH]

Syntax 3:
    WHOAMI /ALL [/FO format] [/NH]

Description:
    This utility can be used to get user name and group information
    along with the respective security identifiers (SID), privileges,
    logon identifier (logon ID) for the current user (access token)
    on the local system. i.e. who is the current logged on user?
    If no switch is specified, tool displays the user name in NTLM
    format (domain\username).

Parameter List:
    /UPN                    Displays the user name in User Principal
                            Name (UPN) format.

    /FQDN                   Displays the user name in Fully Qualified
                            Distinguished Name (FQDN) format.

    /USER                   Displays information on the current user
                            along with the security identifier (SID).

    /GROUPS                 Displays group membership for current user,
                            type of account, security identifiers (SID)
                            and attributes.

    /PRIV                   Displays security privileges of the current
                            user.

    /LOGONID                Displays the logon ID of the current user.

    /ALL                    Displays the current user name, groups
                            belonged to along with the security
                            identifiers (SID) and privileges for the
                            current user access token.

    /FO       format        Specifies the output format to be displayed.
                            Valid values are TABLE, LIST, CSV.
                            Column headings are not displayed with CSV
                            format. Default format is TABLE.

    /NH                     Specifies that the column header should not
                            be displayed in the output. This is
                            valid only for TABLE and CSV formats.
    /?                      Displays this help message.

Examples:
    WHOAMI
    WHOAMI /UPN
    WHOAMI /FQDN
    WHOAMI /LOGONID
    WHOAMI /USER
    WHOAMI /USER /FO LIST
    WHOAMI /USER /FO CSV
    WHOAMI /GROUPS
    WHOAMI /GROUPS /FO CSV /NH
    WHOAMI /PRIV
    WHOAMI /PRIV /FO TABLE
    WHOAMI /USER /GROUPS
    WHOAMI /USER /GROUPS /PRIV
    WHOAMI /ALL
    WHOAMI /ALL /FO LIST
    WHOAMI /ALL /FO CSV /NH
    WHOAMI /?

whoami can be used to determine what security groups are contained in your own access token, but it cannot be used to determine what security groups are contained in another user's access token.

How to View Another User's Windows Access Token

Our Gold Finger Active Directory Audit Tool can be used to determine what security groups are contained in any domain user account's access-token. In fact, you can even use it to view an Active Directory / Windows domain user's access token in an Active Directory environment.

Gold Finger - Windows Access Token Viewer

Gold Finger's Active Directory Security Analysis capabilities are endorsed by Microsoft Corporation.

For more information, and to learn more about Gold Finger's Windows Access Token Viewer capabilities, please visit - http://www.paramountdefenses.com/goldfinger.html

How to Prevent Token Bloat - How to Prevent and Avoid Kerberos MaxTokenSize 1024 SID Limitation Group Membership Based Token Bloat Attacks

If you're a Windows / Active Directory IT Administrator, you are probably already aware of the Kerberos MaxTokenSize 1024 SID Limitation Group Membership Based Token Bloat Issue.

How to Prevent and Avoid Kerberos MaxTokenSize 1024 SID Limitation Group Membership Based Token Bloat Attacks

In essence, as you may know the issue is that by default Kerberos is the authentication protocol used in Microsoft Windows Server environments, and every user ia authenticated has an access token that is associated with his/her logon. Now it so happens that there is a data-structure limitation in the access-token structure due to which an access token cannot contain a maximum of 1024 security identifiers (SID).

( If you're a detail-oriented technical perons, the issue is that there is a hard-coded limit of 1,024 SIDs for the Kerberos PAC (privilege attribute certificate.))

Nested Group Memberships in Active Directory

So the issue is that if a user is made a member of more than 1024 security groups, he/she may not be able to logon because when he/she attempts to logon, the system will proceed to build an access token for the use, and while building the user it will calculate and enumerate all of the user's security group memberships, and once it hits the 1024 SID limit, it will basically stop proceeding to build the access-token due to the data structure limit, and as a result the user will not be able to logon.

Realistically, it is not very easy for a user to be a member of so many groups, but in large companies and in large environments the possibility does certainly exist. In fact, this issue surfaced way back in 2005 when our CEO, then Microsoft Program Manager for Active Directory Security was the lead person working on this issue for Microsoft, and as a result of much of his work, Microsoft later released a whitepaper on the subject, which was authored by Chris Macaulay of Microsoft.



Avoiding Kerberos MaxTokenSize 1024 SID Limitation Group Membership Based Token Bloat Attacks

Anyway, so the point is that this issue can be avoided if you can identify how many SIDs are currently showing up in a user's access token. Now, this theoretically sounds simple, and while you might think that one can just sue a tool like whoami to view a user's token, the thing is that whoami does not have the ability to view another user's access token, but in fact can only be used to view the contents of your own access token.

whoami

In fact, it is not easy to view another user's access token, and no amount of basic LDAP scripting or PowerShell can help you view the complete list of all SIDs in another user's access token, because the contents of a user's access token depend on which domain a user belongs to, which domain the computer on which the logon is being performed belongs to and whether the computer is a member-server or a domain controller (DC), so including each of these factors correctly is not trivial.

Thus, in order to view another user's access token, you essentially need to be able to simulate the Windows access-token generation algorithms and ensure that only those groups that should rightfully belong in a user's token, end up in the access token. This is very difficult to accomplish accurately and is a process that is best automated.

Our Gold Finger Active Directory Audit Tool is the world's first and only tool that simulates the Windows access-token generation algorithms, taking into account all relevant factors such as those mentioned above to determine and reveal exactly what the contents of a user's access token is based on which domain he/she is logging on to, and based on whether he/she is logging on to a member server or a DC.

Windows / Active Directory Access Token Viewer

Gold Finger's Access Token Viewer capability can thus help IT admins instantly view the complete access token of any user in any domain in an Active Directory forest, and thereby help them instantly find out who many SIDs are currently in the user's access token, and accordingly determine whether or not a given account may be at the risk of experience a logon denial-of-service attack.

In addition, Gold Finger's effective delegated access reports capability can also help ensure how many individuals in an organization can create group memberships in the Active Directory, and/or change the membership of an existing Active Directory security group. This information is very valuable because it can be used to prevent someone from being able to maliciously create 1024 groups, make them a member of each other and then just add Authenticated Users to one of these groups, resulting in a organization-wide denial of service attack that can be very expensive to recover from.

In addition, if someone were to make a Domain Controller a member of one of these 1024 groups, the that DC's account could be prevented from replicating with other DC replication partners, and this could substantially affect the proper functioning of an Active Directory environment.

In summary, Kerberos MaxTokenSize 1024 SID limitation group membership based token bloat attacks can today certainly be prevented and avoided, and any users that might be at risk can be easily identified within seconds, thus ensuring that they do not suffer a logon based denial-of-service attack.

To learn more about Gold Finger's access-token viewer capability, please visit -
www.paramountdefenses.com/goldfinger_capabilities_access_token_viewer_for_active_directory