How to view / list /enumerate the list of security groups in a Windows Security Access Token?

In IT infrastructures powered by Microsoft's Windows Server platform, users typically logon to the network with their domain user account, which is stored in, protected in and authenticated by Active Directory.

whoami

When a user logs on to a Windows machine, the system generates an access token for the user.
The information contained in the access token is used to make access decisions whenever the user attempts to requests access to a secured resource on that system.

This access token contains a list of all the security groups that the user belongs to, including all the domain security groups to which the user belongs. In addition, the access token contains a list of all the user rights and privileges that are assigned to the user during that logon session.

In regards to the list of all domain security groups contained a user's token, they include all universal, domain local and global groups that the user belongs to, as well as domain specific builtin domain security groups. Finally the access token also contains a list of any machine local security groups to which he/she belongs.

Sometimes IT personnel have a need to be able to view / see / list /enumerate the list of security groups in a specific user's access token. For instance, sometimes is may be necessary to peek into a user's token to troubleshoot access control / access denied errors. Other times, IT personnel may need to view this information to see what security groups are showing up in a administrative user's token for maintaining Active Directory security.

It is fairly easy to view the contents of one's own access token. This can be done by using the free Microsoft utility whoami. However, it is not very easy to view the contents of another user's access token.

In order to help IT personnel be able to fulfill the need to see / list /enumerate the list of security groups of another user's access token, we added a Windows Token Viewer capability to our Gold Finger tool. With this capability, IT personnel can easily enumerate the list of all security groups that show up in any user's access token.

Gold Finger - Windows Security Access Token Viewer

To view a specific user's access token, you simply specify the user, select a domain, and a target, then click the Gold Finger button. Within seconds, Gold Finger determines and enumerates the list of all domain security groups that show up in the user's token. You can then easily export this list.

(Incidentally, the Gold Finger tool was initially designed to help organizations protect themselves from the most critical of all Active Directory Security Risks, which could potentially be exploited by an advanced persistent threat seeking to inflict damage to a specific organization or organizations.)

With Gold Finger's Token Viewer capability, IT personnel can now easily view the contents of any domain user/computer account's access token, in any Active Directory environment. For more information on this capability, and to download a free trial, please visit our website.

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

How to View a Windows User Account's Access Token

In Microsoft Windows based systems, each user has a user account with which he/she logs on, and each account is represented by a unique Security Identifier (SID) that uniquely represents that account across the system.

User accounts are generally of two types - local user accounts and domain user accounts.

A local user account is an account that is local to a single machine running a version of Microsoft's family of operating systems, such as Windows XP, Windows 7, Windows Server 2008 etc. A local account can only be authenticated by the local machine and used on the local machine.

In contrast, a domain user account is an account that belongs to an Active Directory domain in Microsoft Windows Server environments. A domain user account is authenticated by the Active Directory and can be used on any domain-joined machine that belongs to the same domain as does the domain user account, or to a domain or forest with which there exists a trust relationship with the domain/forest of the domain user account.

User accounts almost always are made members of security groups. These security groups can be local security groups or domain security groups. Domain security groups (also known as Active Directory Security Groups) include domain local groups, global groups, universal groups. Groups can also be of type Builtin on a domain, and such groups are like local groups except that they only exist on all domain controllers of a domain and they can only be used to control access to resources on Domain Controllers.

Group Memberships and Access Tokens together control and enforce access

In most environments, group memberships are used to collectively grant a set of user's access to a set of resources across the system as per the organization's resource authorization model/strategy..


What is an Access Token

The memberships of a domain user account are generally calculated by the system during the user's logon and inserted in a structure known as the user's access token.The user's access token thus contains a list of all security groups to which a user belongs.

An access token is thus used by the system when making access-control decisions, such as when determining whether or not to grant a user the access requested by the user on a resource. The way the system make this determination is to compare SIDs in the resource's access control list (ACL) with the SIDs in the user's access token. If an "allow" match is found, access is granted.

It is often helpful to be able to view a user's access token. The most important thing one can find out by looking at a user's access token is what security groups the user belongs to. This information can be very helpful when trying to find out what all the user might have access to.

However this information can also be sensitive, because for example, the name of the groups could reveal certain sensitive aspects about a user's status at an organization. For instance, if a user is being tracked for suspicious activity, and he/she is made a member of a group called "Monitored Users", anyone who could view the user's access token could find out that this is user's activity is being monitored.



Viewing Access Tokens

All users can view their own access token at anytime, and Microsoft provides tools to be able to view access tokens, such as the whoami utility, which can be used to peek into one's own token.

Using whoami to view one's own access token

However, it is very difficult to be able to look into another user's token, because the algorithm involved in generating/computing a user's access token is very sophisticated, and although it is baked into the operating system, it is not easy to try and simulate/calculate with sufficient level of accuracy.

As a result, IT administrators and IT security personnel do not have the means to be able to view into another user's access token. There are ways like KerberosS4U that can be used to try and obtain a logon session for another user's behalf, or Delegation of Authentication, which can also be used to impersonate another user, but these ways do not provide an easy means by which to view another user's access token.

Gold Finger's access token viewer is unique in that regard, in that it lets IT personnel easily view the access token of any domain user account. It is arguably the only automated access token viewer capability for the Microsoft Windows platform, and it makes viewing another user's token, as easy as touching a button.

Using Gold Finger to View Another User's Access Token

Gold Finger's access token viewer can generate domain-specific access-tokens for any domain user specified by the IT administrator. It takes domain-specific information into account to ensure that the right types of groups from the right domains are included in the simulated access-token.

For example, it ensures that all relevant global groups and universal groups are included from the user's domain, as well as that all relevant domain-local groups are included from the target domain. It also obviously includes any nested group memberships for accuracy, and thus delivers the complete and accurate picture.

Gold Finger's access token viewer capability can be used to determine/analyze -

1. The list of all domain security groups to which a user belongs
2. The list of all domain security groups to which an IT administrator belongs
3. The list of all domain security groups to which an employee belongs
4. The list of all domain security groups to which a contractor's account belongs

This information is also very helpful when trying to find out who has access to a particular file/folder/Active Directory object, because it lets you instantly compare the target object's ACL with the user's access-token and determine whether or not the user has the access in question.

The ability to view a user's access token is thus very valuable and helpful in many situations including when performing an Active Directory Audit, when finding out whether or not a user has access to a specific file/folder, and to find out all what a user might have access to across the system.

For more information on Gold Finger's access token viewing capability, please visit - http://www.paramountdefenses.com/goldfinger_capabilities_access_token_viewer_for_active_directory

The ability to be able to view into a user's Access Token when evaluating Cyber Security related risks to Active Directory deployments in the DMZ, or when auditing security rights in Active Directory. In addition it can be helping when you are trying to list all the groups to which a user belongs.

Windows Security User Access Tokens and an Access Token Viewer

In Microsoft Windows Server based environments, Windows security access tokens play an important role in user authentication and resource authorization.

In particular, in the Microsft security model, two elements come into play during an access authorization check when a user attempts to access a secured resource, such as a file, folder or an Active Directory object. These two elements include the ACL of the secured resource as well as the access token of the user requesting access to the resource.

The ACL on the resource contains a list of security permissions that grant/deny specific access to the securable objects protected by the ACL. Each security permission specifies access for a unique security principal which is identified by a unique Security Identifer (SID.)

The access token of the user requesting access, similar includes a list of all groups to which the user belongs, and in particular, it is the SIDs of these groups that are stored in the access token.

During an access check, the system compares the SIDs in the user's access token with the SIDs in the ACL of the securable object to which access is requested, and based on a comparison, determines whether or not the requested access should be permitted.

The contents of an access token are thus very valuable to look at, because they include all the SIDs to which a user belongs when requesting access to a specific resource. They can however differ based on the type of logon, the domain of the computer on which the target resource resides and the type of machine (DC/member server) on which a user is logging on.

Thus, while it is valuable to be view a user's access token, it is not easy to do so, and while a user can always view the contents of his/her own access token, a user cannot view another user's access token.

The most common way of viewing one's own access token is via the Windows whoami utility -

A specialized access token viewer is a utility that can help users view the access token of another user. Such a utility is commonly referred to as an Access Token Viewer, and it works by simulating the generation of access tokens for users based on the same factors that the system itself uses to generate access tokens.

In this blog, we will take a look the one such Windows Security Access Token Viewer, and see how it can be used to view the access token of any domain user/computer account in an Active Directory environment.

An access token viewer can be an extremely valuable security analysis tool in many scenarios, such as when you're trying to find out whether or not a user has access to a specific file/folder/object.

Sharon.

PS: The ability to view tokens is very helpful in numerous situations including when you are trying to mitigate Active Directory Risks or Cyber Security threats. Token viewer's capabilities can also be helpful when you are trying to enumerate/list/view Active Directory / Domain group memberships and/or when you are trying to determine accounts that might be at close to the 1024 SID Kerberos Token Limitation value.