When working with Windows machines in a corporate environment, it's crucial to understand your effective permissions and group memberships. Domain-joined computers inherit permissions differently from standalone machines, making role verification more complex.

The simplest way to check your current user's group memberships is through the command prompt:


whoami /groups


For a more detailed view of your security context:


whoami /all


This will display your username, SID, groups (both domain and local), and privileges.

PowerShell provides more comprehensive options. Try this command to see all groups where your user is a member:


(New-Object System.DirectoryServices.DirectorySearcher("(&(objectCategory=user)(samAccountName=$env:USERNAME))")).FindOne().GetDirectoryEntry().memberOf


For a cleaner output with just group names:


(New-Object System.DirectoryServices.DirectorySearcher("(&(objectCategory=user)(samAccountName=$env:USERNAME))")).FindOne().GetDirectoryEntry().memberOf | % { [System.Text.Encoding]::Default.GetString([System.Convert]::FromBase64String($_)) }


To understand what permissions you actually have on the local machine, use this PowerShell script:


$identity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$principal = New-Object System.Security.Principal.WindowsPrincipal($identity)

# Check for common roles
"Local Administrators: " + $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
"Power Users: " + $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::PowerUser)
"Users: " + $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::User)


Domain users often have rights assigned through Group Policy. To check these:


gpresult /r


Or for more detailed HTML output:


gpresult /h $env:USERPROFILE\Desktop\GPOReport.html


Here's a complete PowerShell function to check both local and domain roles:


function Get-UserRoles {
[cmdletbinding()]
param()

$output = @{}
$identity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$principal = New-Object System.Security.Principal.WindowsPrincipal($identity)

# Local machine roles
$output.LocalRoles = @{
Administrator = $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
PowerUser = $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::PowerUser)
User = $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::User)
}

# Domain groups (requires RSAT)
try {
$searcher = New-Object System.DirectoryServices.DirectorySearcher
$searcher.Filter = "(&(objectCategory=user)(samAccountName=$($identity.Name.Split('\')[1])))"
$result = $searcher.FindOne()

if ($result) {
$user = $result.GetDirectoryEntry()
$output.DomainGroups = $user.memberOf | ForEach-Object {
$_.ToString().Split(',')[0].Replace("CN=","")
}
}
}
catch {
Write-Warning "Could not query domain groups: $_"
}

return $output
}

# Usage:
Get-UserRoles | ConvertTo-Json -Depth 3


---

When working in a Windows domain environment, it's crucial to verify your effective permissions and group memberships. The domain context adds complexity because your access rights can come from:

• Local machine groups
• Domain groups
• Nested group memberships
• Organizational Unit (OU) policies

For a fast check of your current user's group memberships (both local and domain):

whoami /groups

This returns output showing all security groups where your account has membership, including SIDs and attributes like "Mandatory" or "Enabled by default".

For more detailed analysis, use PowerShell:

$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$currentUser.Groups | ForEach-Object {
    $group = $_.Translate([System.Security.Principal.NTAccount])
    $groupSid = $_.Value
    [PSCustomObject]@{
        GroupName = $group.Value
        SID = $groupSid
        IsDomainGroup = $groupSid -like "S-1-5-21-*"
    }
} | Format-Table -AutoSize

To see what permissions you actually have on specific resources:

# For file system permissions
$path = "C:\\SensitiveFolder"
$accessRules = (Get-Acl $path).Access
$accessRules | Where-Object { $_.IdentityReference -eq $env:USERNAME }

# For registry permissions
$regPath = "HKLM:\\Software\\YourApp"
(Get-Acl $regPath).Access | Where-Object { 
    $_.IdentityReference -eq $env:USERDOMAIN + "\\" + $env:USERNAME 
}

Domain users often need to check GPO-applied restrictions:

gpresult /r /scope user

Combine with HTML output for better readability:

gpresult /h $env:USERPROFILE\\Desktop\\GPOReport.html

Here's a comprehensive script that checks multiple permission aspects:

function Get-UserSecurityContext {
    param([string]$ComputerName = $env:COMPUTERNAME)

    $output = @{
        UserName = "$env:USERDOMAIN\\$env:USERNAME"
        Computer = $ComputerName
        LocalGroups = @()
        DomainGroups = @()
        Privileges = @()
    }

    # Get local group memberships
    $localGroups = net localgroup | Where-Object { $_ -match "^-+" -replace "-" }
    foreach ($group in $localGroups) {
        $members = net localgroup $group | Where-Object { $_ -match $env:USERNAME }
        if ($members) {
            $output.LocalGroups += $group
        }
    }

    # Get domain group memberships
    $user = [ADSI]"WinNT://$env:USERDOMAIN/$env:USERNAME"
    $groups = $user.Groups()
    foreach ($group in $groups) {
        $output.DomainGroups += $group.Name
    }

    # Get privileges
    $output.Privileges = whoami /priv | Where-Object { $_ -match "Se" }

    return [PSCustomObject]$output
}

Get-UserSecurityContext | Format-List

Case 1: When you see access denied but groups suggest you should have access:

# Check token elevation status
[Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent() | 
Select-Object IsInRoleAdministrator

Case 2: When nested group permissions aren't applying:

# Force group policy update
gpupdate /force

# Refresh security token
klist purge