Background Information:
We want to determine, given a specific user, what lists/libraries he has access to in our SharePoint environment, and what access level he has. We want to automate this discovery process using a PowerShell script that will run on the SharePoint server directly, and will prompt the user executing the script to input the user name of the user for which we want to investigate the access rights for. The end goal of the script will be to produce a report listing all artefacts the user has access to, and what access levels he has to them.
How are Permissions Given in the SharePoint Object Model:
Basically, in the SharePoint world, we can set unique permissions down to the item level, but since all we are worried about is Lists, we won’t have to worry about this level of granularity. The SharePoint Object Model stores permissions into what Microsoft calls Role Assignments. A Role Assignment in the SharePoint world is basically a mapping between a user, a SharePoint artefact (Web, List, etc.) and a Role (Design, Full Control, Contribute, etc).
Script’s Logic:
Our script will require two inputs from the user, the URL of the Web Application to look for the user’s permissions, and off course the login name of the user. The script will loop through all site collections in the Web Application, through all webs, and through all lists, it will gather information about where the user has access and will print a detailed report out to the PowerShell console.
Add-PSSnapin Microsoft.SharePoint.PowerShell
$url = Read-Host “URL of the Web Application”
$userName = Read-Host “User Name”
$webApp = Get-SPWebApplication $url
$report = “”
$newLine = “`r`n”
Write-Host “Report for” $userName -BackgroundColor Blue -ForegroundColor White
# Loop through all site collections
foreach($site in $webApp.Sites)
{
# Loop through all webs
foreach($web in $site.AllWebs)
{
# Get a reference to the SharePoint user object
$user = $web.EnsureUser($userName)
# Loop through all lists in the current Web
$alreadyFoundInCurrentWeb = $false
foreach($list in $web.Lists)
{
# Skip hidden lists (normally system reserved)
if($list.Hidden -ne $true)
{
# Get Role Assignments for the current user
$roleAssignments = $list.RoleAssignments.GetAssignmentByPrincipal($user)
$curBinds = “”
# Loop through all role assignments
foreach($role in $roleAssignments)
{
# Loop through all permission levels
$bindings = $role.RoleDefinitionBindings
foreach($bind in $bindings)
{
$curBinds += $bind.Name + “,”
}
}
if($curBinds -ne “”)
{
if($alreadyFoundInCurrentWeb -eq $false)
{
$report += $web.Url + $newLine
$alreadyFoundInCurrentWeb = $true
}
# Remove trailing comma in bindings list
$curBinds = $curBinds.Substring(0, $curBinds.Length -1)
$report += ” ” + $list.Title + ” –> ” + $curBinds + $newLine
}
}
}
$web.Dispose()
}
$site.Dispose()
}
Write-Host $report
Summary:
PowerShell only offers cmdlets for SharePoint down to the Web level. As soon as you start playing with lists and lower objects, a complete understanding of how the SharePoint object model works in the back-end is crucial. Remember, PowerShell bridges the gap between developers and IT Pros, but you require knowledge of both worlds in order to use it to its full potential!
