Ever wondered exactly what permissions a given user has? A user can be a member of a user role directly, but a user can also be a member of a user via membership in an Active Directory group that is a member of a user role. Further, a user can be a member of a group which is a member of a group which is a member of a group which is a member of a user role. You get the idea.
Going through each user role, looking at each group in the user role, and then going to active directory to look at the members of that group, and the members of the groups in that group, and so on can be very intimidating and a big waste of time.
So, let’s let the magic of PowerShell do the work for us!
Awhile ago, I wrote a PowerShell script that will display the display name of the user roles, the user role profile that each of the user roles are based on, all of the users in each user role (including groups) and the permissions that are available to members of each of the user roles. You can find this blog post and the PowerShell script here:
http://blogs.technet.com/b/servicemanager/archive/2011/12/01/userroles-powershell-report-using-smlets.aspx
So – now what we are going to do is combine that with some other PowerShell magic using the Active Directory module. Basically, what this new Get-UserPermissions.ps1 PowerShell script does is:
- Get all user roles using Get-SCSMUserRole from SMLets (what would we do without SMLets??)
- For each user role, get the members of the user role
- For each member of the user role, determine if the member is a User or a Group by using the Get-ADObject cmdlet and then testing the .ObjectType property of the returned object. If the ObjectType = User then we know it is a user or if it is a Group then we know it is a group.
- If it is a user, then we test to see if the user’s name is the same as the one that are looking for. If it is, then we stop there and tell the person running the script that the user is directly a member of this user role and prompt whether or not to show the permissions for that user role or not.
- If it is a group then we test to see if the user is a member of the group recursively using the Get-ADGroupMember cmdlet using the -Recursive parameter. We compare all the users returned by this cmdlet to the username of the user that we are looking for. If there is a match, then we inform the person running the script that the user is a member of the user role via membership in that group and prompt whether or not to display the permissions of that user role.
Simple enough right?
This is what the script looks like in action:
I’ve made the script available on the TechNet Gallery here:
http://gallery.technet.microsoft.com/Service-Manager-SCSM-User-ebcdfcd6
Enjoy!
 |
Travis Wright Partner, Director of Product Management Cireson |
   |
Follow Me! |
Ready to transform your SCSM experience? View all of the exciting apps Cireson has to offer.
