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”.