Skip to content

Roleassignments Remove All Search

Get-AzureADServiceAppRoleAssignment

Gets a service principal application role assignment.

Syntax

Description

The Get-AzureADServiceAppRoleAssignment cmdlet gets a role assignment for a service principal application in Azure Active Directory (AD).

Examples

Example 1: Retrieve the application role assignments for a service principal

The first command gets the ID of a service principal by using the Get-AzureADServicePrincipal cmdlet. The command stores the ID in the $ServicePrincipalId variable.

The second command gets the application role assignments for the service principal in identified by $ServicePrincipalId.

Required Parameters

-ObjectId

Specifies the ID of a service principal in Azure AD.

Type:String
Position:Named
Default value:None
Accept pipeline input:True (ByPropertyName, ByValue)
Accept wildcard characters:False

Optional Parameters

-All

If true, return all application role assignments. If false, return the number of objects specified by the Top parameter

Type:Boolean
Position:Named
Default value:None
Accept pipeline input:True (ByPropertyName, ByValue)
Accept wildcard characters:False

-Top

The maximum number of records to return.

Type:Int32
Position:Named
Default value:None
Accept pipeline input:True (ByPropertyName, ByValue)
Accept wildcard characters:False

Related Links

This is an interesting “feature” of the SharePoint 2007 permission model that I came across today. Well imagine you have a site and a couple of lists in your site and all of them have unique permissions. If you check the value of the HasUniqueRoleAssignments property of the site and the lists they will all return “true“. So what does this tell you?  Well they are unique and independent and if you change the role assignments of the site this wouldn’t affect the role assignments of the lists and vice-versa, right? Well not exactly …

For a user to have any permissions granted for a list, this same user should also have site permissions granted. When you add someone as a list “Reader” for example then SharePoint will also add “Limited Access” permissions for the same user at the site level. SharePoint will create a new SPRoleAssignment at the site level, or will use an existing one if this user already has any permissions defined at the site level, and then will add a “Limited AccessSPRoleDefinition to the role assignment. It will do this without asking you or telling you about it.

Now if you decide to delete the role assignment for this user at the site level, guess what will happen? Well SharePoint will also delete the role assignment for the same user in all lists that have (not so) unique role assignments. And this means deleting any and all permissions granted to this user in any of the lists. Again it will not ask you and will not tell you it has done it. It would have been nice if there was an exception thrown but there isn’t.

So what this means for you. Well if you are dealing with permissions and you want to re-apply or change the site level permissions then if you were thinking about first removing all role assignments and then re-adding them this will actually also delete all role assignments from all lists in this site even if those lists have unique role assignments. So if that’s not what you expected how to get around it? Well instead of removing all the role assignments at the site level, just remove the role definition bindings from each of the role assignments:

foreach (SPRoleAssignment roleAssignment in web.RoleAssignments)

{

roleAssignment.RoleDefinitionBindings.RemoveAll();

roleAssignment.Update();

}

Doing so will NOT delete the “Limited Access” role definition binding from the site role assignments and your list permissions will remain untouched. Actually SharePoint doesn’t allow you to add or remove “Limited Access” permission directly and manages this internally.

Like this:

LikeLoading...

Related

Comments (4)