In a larger environment, or more-so an environment which is quiet old, security groups fester. It’s just a fact of life.

You add a user to a few groups, they suddenly have access to a published app. You remove the obvious culprit, but they still have access.

Manually, it would take you months or years to find the sneaky group link. Until now.

  
import-module activedirectory
  
$username = read-host "What's their username?"
  
Function RecurseUsersInGroup {
     
Param ([string]$object = "", [int]$level = 0)
     
$indent = "-" * $level
     
$indent2 = "=" * $level

$x = Get-ADObject -Identity $object -Properties SamAccountName

if ($x.ObjectClass -eq "group") {
         
Write-Host "$indent2# $($x.SamAccountName)"

$y = Get-ADGroup -Identity $object -Properties Members

$y.Members | %{
             
$o = Get-ADObject -Identity $_ -Properties SamAccountName

if ($o.ObjectClass -eq "user" -and $o.SamAccountName -eq $username) {
                 
Write-Host "$indent-> $($o.SamAccountName)"
             
} elseif ($o.ObjectClass -eq "group") {
                 
RecurseUsersInGroup $o.DistinguishedName ($level + 1)
             
}
         
}
     
} else {
         
Write-Host "$($object) is not a group, it is a $($x.ObjectClass)"
     
}
  
}
  
$thegroup = read-host "What's the Group?"
  
RecurseUsersInGroup (get-adgroup $thegroup).DistinguishedName

What it looks like:

  
PS D:\Profiles\admin> script.ps1
  
What's their username?: testuser
  
What's the Group?: Test Group 1
  
\# Test Group 1

  
=# Test Group 2

  
==# Test Group 3

  
---> testuser

PS D:\Profiles\admin>

So in the above example, “Test Group 1” has been configured for our published resource (app/desktop). However, there are several layers of nesting, and our test user will get access even though they’re a member of “Test Group 3”.